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

5

Eu uso o btrfs com o Linux 4.10.8. Depois de uma reinicialização difícil, o Google Chrome alegou que não conseguiu encontrar os dados locais. Algumas voltaram assim que adicionei os IDs de usuário relevantes, então fiquei curioso sobre o que estava acontecendo. Eu olhei em ~ / .config / google-chrome, e achei isso:

$ ls -i 

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

Esse é o mesmo arquivo, com o mesmo inode, duas vezes. Eu estou supondo que isso pode ser porque o Google Chrome ficou confuso, embora pareça funcionar bem entre cada reinicialização - escrevendo muito para este arquivo Local \ State. Quando eu reinicio, no entanto, ele diz que é incapaz de carregar o estado local. Nem o SMART verifica nem o btrfsck relata erros. Alguma idéia?

    
por sigvei 14.04.2017 / 22:54

1 resposta

2

Eu tenho o mesmo problema no btrfs com o kernel 4.14.0 , mas 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.old obtenho:

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

Neste ponto, reiniciei o 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 ser capaz de começar de lá, mas eu estou deixando os outros passos que tomei para a perfeição.

    
por 01.01.2018 / 20:39