Listar arquivos no diretório: saída estranha

Question

Eu estava tentando listar arquivos em algum diretório, mas estou obtendo resultados estranhos.

Este é o comando que eu digito no prompt de comando: dir *t.*

Este é o resultado:

c:\test.1.1990.txt
c:\test.31.1990.txt
c:\test.txttxt
c:\test.11.2007.txtGif
c:\test.1.1990.txt
c:\test.31.1990.txt
c:\test.tGift
c:\test.txtGif
c:\testbbb.exeTxt
c:\test\test.txt

A 9ª saída é particularmente estranha: 5bbb.exeTxt , por que recebi esse resultado considerando minha consulta? (agora que eu vejo, a maioria dos resultados parece estranha?) por exemplo, por que 2?

Alguém por favor pode explicar?

Vou precisar usar o método GetFiles , que funciona da mesma forma, eu acho, é por isso que estou interessado.

Related: List files in folder which match pattern (Stack Overflow)

    

Answer 1

Eu suspeito que seja por causa do comportamento mencionado no blog de Raymond Chen (aviso - não documentação real).

For example, if your pattern ends in .*, the .* is ignored. Without this rule, the pattern *.* would match only files that contained a dot, which would break probably 90% of all the batch files on the planet, as well as everybody's muscle memory, since everybody running Windows NT 3.1 grew up in a world where *.* meant all files.

Seu padrão é *t.* , que é alterado para, suponho, *t , que corresponde a 5bbb.exeTxt . Não tenho certeza de como DirectoryInfo.GetFiles funciona, por que não apenas testá-lo?

Parece que os nomes curtos também são correspondidos ou os três primeiros caracteres da extensão.

G:\junk\filetest>dir
 Volume in drive G is Extended2
 Volume Serial Number is 3E2F-7A67

 Directory of G:\junk\filetest

09/09/2014  10:01 AM    <DIR>          .
09/09/2014  10:01 AM    <DIR>          ..
09/09/2014  09:59 AM                 6 test.txtR
09/09/2014  10:01 AM                 2 test.txtrrr
               2 File(s)              8 bytes
               2 Dir(s)  162,957,000,704 bytes free

G:\junk\filetest>dir *.txt
 Volume in drive G is Extended2
 Volume Serial Number is 3E2F-7A67

 Directory of G:\junk\filetest

09/09/2014  09:59 AM                 6 test.txtR
09/09/2014  10:01 AM                 2 test.txtrrr
               2 File(s)              8 bytes
               0 Dir(s)  162,957,000,704 bytes free

G:\junk\filetest>dir /x *.txt
 Volume in drive G is Extended2
 Volume Serial Number is 3E2F-7A67

 Directory of G:\junk\filetest

09/09/2014  09:59 AM                 6 TEST~1.TXT   test.txtR
09/09/2014  10:01 AM                 2 TEST~2.TXT   test.txtrrr
               2 File(s)              8 bytes
               0 Dir(s)  162,957,000,704 bytes free

    

Answer 2

Eu acho que @dsolimano (e sua fonte, Raymond Chen) ficou bem perto do seu problema, mas talvez não tenha a explicação correta. Depois de pensar, pesquisar e testar, embora eu ainda tenha que criar uma documentação para comprovar isso, acredito que cheguei a uma conclusão razoavelmente precisa.

Minha hipótese é baseada em um comportamento um pouco relacionado em nomes de domínio e alguns outros recursos de computador nomeados. Com nomes de domínio, há um ponto final implícito no final. Portanto, www.superuser.com é realmente www.superuser.com. . Minha conclusão, depois de alguns testes, é que a API do Windows (se não o próprio sistema de arquivos) usa a mesma convenção para nomes de arquivos.

Pense em todos os nomes de arquivos que você forneceu que correspondem ao seu resultado. Se você considerar que nomes de arquivos 8.3 estão incluídos nas pesquisas, conforme descrito aqui , e suponha que nomes extensos de arquivos com um ponto final e 8.3 nomes de arquivo com um ponto final também estão incluídos, você verá que cada um desses arquivos corresponde por pelo menos uma versão do seu nome de arquivo. (Lembre-se de que o curinga * é um marcador que representa "qualquer número de caracteres ou nenhum caractere".)

• c:\test.1.1990.txt corresponde como 1.1.1990.txt. ou 111990~1.TXT.
• c:\test.31.1990.txt corresponde como 1.31.1990.txt. ou 131199~1.TXT.
• c:\test.txttxt corresponde como 1.txttxt. ou 1956B~1.TXT.
• c:\test.11.2007.txtGif corresponde como 111120~1.TXT.
• c:\test.1.1990.txt corresponde como 12.1.1990.txt. ou 12199~1.TXT.
• c:\test.31.1990.txt corresponde como 12.31.1990.txt ou 123119~1.TXT.
• c:\test.tGift corresponde como 2.tGift.
• c:\test.txtGif corresponde como 2BEFD~1.TXT.
• c:\testbbb.exeTxt corresponde como 5bbb.exeTxt.
• c:\test\test.txt corresponde como test.txt ou test.txt.

Você pode testar isso criando uma série de arquivos de teste em C:\test , conforme descrito abaixo, e executando dir *t.* novamente.

1. Um arquivo com uma extensão que termina em "t".
2. Um arquivo com o nome terminando em "t".
3. Um arquivo com uma extensão maior que três letras com a terceira letra na extensão sendo "t".
4. Alguns arquivos que correspondem a mais de um dos critérios acima.
5. Um arquivo com o nome terminando em "t" e sem nenhuma extensão.
6. Alguns arquivos que não atendem a nenhum dos critérios acima.

Você deve ver, como eu, que dir *t.* retornará apenas arquivos que se encaixem nas categorias 1-5 acima. Arquivos na categoria 6 serão excluídos. Você também pode descartar o método GetFiles mais diretamente contra os mesmos arquivos com o PowerShell, usando o comando abaixo, e deverá ver os mesmos resultados.

[IO.Directory]::GetFiles('C:\test','*t.*')