btrfs: ls lista o mesmo arquivo duas vezes no diretório

btrfs: ls lista o mesmo arquivo duas vezes no diretório

Eu uso btrfs com Linux 4.10.8. Após uma reinicialização forçada, o Google Chrome alegou que não conseguiu encontrar os dados locais. Parte disso voltou assim que adicionei os IDs de usuário relevantes, então fiquei curioso para saber o que estava acontecendo. Procurei em ~/.config/google-chrome e encontrei isto:

$ ls -i 

...
3529523 'Local State'
3529523 'Local State'
...

É o mesmo arquivo, com o mesmo inode, duas vezes. Suponho que seja por isso que o Google Chrome ficou confuso, embora pareça funcionar bem entre cada reinicialização – gravando muito neste arquivo Local\State. Quando eu reinicio, no entanto, ele diz que não é possível carregar o estado local. Nem as verificações SMART nem o btrfsck relatam erros. Alguma ideia?

Responder1

Eu tenho o mesmo problema no btrfs com kernel, 4.14.0mas meu arquivo duplicado era .config/google-chrome-unstable/Default/TransportSecurity. Consegui consertar fazendo

cd .config/google-chrome-unstable/Default
mkdir -p ~/tmp/Default
chmod 700 ~/tmp/Default
tar cf - . | (cd ~/tmp/Default && tar xf -)
cd ~
rm -rf .config/google-chrome-unstable/Default # this will error because the directory isn't empty because the duplicated file left some residue
mv .config/google-chrome-unstable/Default{,.old}
mv ~/tmp/Default .config/google-chrome-unstable/

Agora quando eu ls -l .config/google-chrome-unstable/Default.oldrecebo:

ls: cannot access '.config/google-chrome-unstable/Default.old/TransportSecurity': No such file or directory
total 0
-????????? ? ? ? ?            ? TransportSecurity

Neste ponto, reiniciei no modo de usuário único e executei:

umount /home
btrfs check --repair /dev/sdc1

Ele notou o diretório corrompido e o reparou. Você pode simplesmente começar a partir daí, mas estou deixando as outras etapas que executei para completar.

informação relacionada