Eu estava assistindo ao vídeo do FlyTech , e quando ele fez um par de pastas ilegais (uma chamada "<" e outra chamada ">"), isso fez o Windows pensar que a pasta que as continha estava corrompida. Esse comportamento não parece ocorrer para qualquer uma das outras pastas com caracteres ilegais.
Eu queria saber por que essa combinação específica faz o Windows pensar que a pasta que a contém está corrompida. Pesquisei um pouco e não consegui encontrar o porquê disso. Alguém poderia explicar?
O erro não é causado exatamente por colchetes angulares ou por ter dois deles - em vez disso, ocorre quando 1) um nome de arquivo contém caracteres curinga em seu nome e 2) o curinga corresponderia a um arquivo visto anteriormente , o que resulta em Windows pensando que a pesquisa de pastas não avança como deveria.
Primeiro, pelo que entendi, listar um diretório no Windows é feito por expansão curinga (o oposto de como seria feito no Linux). Para expandir um padrão curinga, comece chamando FindFirstFile() com o padrão inicial e, em seguida, repita FindNextFile() enquanto o NTFS encontra os arquivos correspondentes um por um. Para listar o diretório inteiro, faça o mesmo com
*
o padrão.Em segundo lugar, ambos
<
e>
(assim como"
) são realmente tratados como curingas nas partes mais profundas do código de manipulação de arquivos do Windows – eles se comportam como as variantes curingas históricas do MS-DOS*
de e?
. (Por exemplo,>
também conhecido como DOS_STAR corresponde a todos os caracteres até a extensão do arquivo.) O código-fonte .NET disponível publicamente contém uma descrição do algoritmo, que é idêntico ao encontrado na fonte do kernel do Windows NT vazada.Portanto, não são apenas os colchetes angulares, mas também
"
?
*
podem ser usados para acionar esse erro - desde que sejam usados em combinação com outro nome de arquivo que seria classificado antes do curinga, se a classificação for feita pelo valor Unicode (que é a ordem imposta pelo NTFS).Por exemplo, você também receberia o erro "pasta corrompida" se tivesse itens nomeados
foo(
efoo*
. Não há nada de especial sobre o(
aqui, exceto que ele vem antes*
em Unicode – enquanto um caractere que classifica depois*
, comofoo+
não acionaria o erro. (Você pode abrir o "Mapa de Caracteres" via charmap.exe se quiser ver as posições Unicode desses caracteres.)Da mesma forma, um diretório contendo [
foo<
,foo=
] ou [foo?
,fooo
] não acionaria essa situação, mas um diretório contendo [foo=
,foo>
] ou [foo+
,foo?
] o faria.Então, se eu entendi tudo corretamente, o que parece acontecer é:
foo(
,foo*
], com o NTFS aplicando essa ordem exata.*
".foo(
.foo(
".foo(
(correspondência exata) e retorna o próximo itemfoo*
.foo*
".foo*
– que é reconhecido como um curinga e correspondefoo(
primeiro, portanto, o próximo item éfoo*
novamente – então um erro é gerado.Como
>
é tratado de forma semelhante ao*
curinga, uma pasta chamada ">
" causa o mesmo problema ao combinar o<
item " " anterior antes de si mesmo.Caracteres
<
e>
pertencem ao grupo "caracteres reservados", que não deve ser usado para nomear um arquivo ou diretório no Windows.https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
Conforme observado em outra resposta, esses caracteres estão no grupo de caracteres reservados:
https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
Há razões muito específicas para cada uma delas. Existem maneiras de contorná-los, mas cada um tem uma função fundamental no processamento de comandos: