btrfs: ls enumera el mismo archivo dos veces en el directorio

btrfs: ls enumera el mismo archivo dos veces en el directorio

Yo uso btrfs con Linux 4.10.8. Después de un reinicio completo, Google Chrome afirmó que no pudo encontrar los datos locales. Parte de esto volvió tan pronto como agregué las ID de usuario relevantes, así que tenía curiosidad por saber qué estaba pasando. Miré en ~/.config/google-chrome y encontré esto:

$ ls -i 

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

Es el mismo archivo, con el mismo inodo, dos veces. Supongo que esta podría ser la razón por la que Google Chrome se confundió, aunque parece funcionar bien entre cada reinicio, escribiendo mucho en este archivo Local\State. Sin embargo, cuando lo reinicio, dice que no puede cargar el estado local. Ni las comprobaciones SMART ni btrfsck informan ningún error. ¿Algunas ideas?

Respuesta1

Tengo el mismo problema en btrfs con kernel 4.14.0pero mi archivo duplicado era .config/google-chrome-unstable/Default/TransportSecurity. Pude solucionarlo haciendo

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/

Ahora cuando ls -l .config/google-chrome-unstable/Default.oldobtengo:

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

En este punto reinicié en modo de usuario único y ejecuté:

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

Se dio cuenta del directorio dañado y lo reparó. Es posible que puedas comenzar desde allí, pero dejaré los otros pasos que tomé para que estén completos.

información relacionada