Estou caçando um bug muito estranho:
arian@orel:~$ ls ._cache.<tab><tab>
Display all 205 possibilities? (y or n)
._cache.apt-file/
._cache.chromium/
._cache.chromium.Default/
._cache.chromium.Default.Cache/
._cache.chromium.Default.Media Cache/
._cache.dconf/
._cache.evolution.mail/
._cache.evolution.mail.1370283652_17412_21@orel/
[email protected]/
[email protected]/
._cache.evolution.mail.1370283652_17412_21@orel.folders.Archives.subfolders/
...
é como se o ponto funcionasse como um separador de caminho, exceto que a conclusão da guia não o trata como um separador de caminho e exibe o diretório recursivamente. Eu vi esse comportamento apenas neste diretório. Nem em diretórios pai nem filho e não está em um sistema de arquivos separado. Isso também mostra quando acessado a partir da mídia de instalação, portanto, não parece ser o meu sistema operacional. Também mostra ao acessar via sshfs. ls
e find
mostram apenas caminhos normais, mas du
também mostra esses períodos.
fiz o fsck no FS
Eu notei um arquivo chamado
playlist.pls\?action\=playlist\&type\=pls\&sid\=545\&stream_id\=1711
no diretório. ao mover isso para outro lugar, o comportamento desapareceu. Então parece que há algum bug em lidar com esses personagens, certo? Bem, eu posso chdir onde eu mudei o arquivo, criei alguns arquivos e diretórios e este comportamento não apareceu.
Eu touch
alguns arquivos com \&
, \?
e \=
e combinações em seus nomes, com comportamento normal.
Eu movi o arquivo playlist.pls\?action\=playlist\&type\=pls\&sid\=545\&stream_id\=1711
de volta e nenhum comportamento anormal apareceu.
Não tenho muita certeza sobre o que fazer aqui. Existe algum bug com certeza, pelo menos o fsck deve detectar um possível erro no disco se todo o código funcionasse corretamente, certo? Eu também não tenho ideia de qual código está com defeito.
Eu não consegui reproduzir esse bug depois que movi o arquivo.