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.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
recebo:
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.