Ich verwende btrfs mit Linux 4.10.8. Nach einem Hard-Reboot behauptete Google Chrome, die lokalen Daten nicht finden zu können. Einige davon kamen zurück, sobald ich die entsprechenden Benutzer-IDs hinzufügte, also war ich neugierig, was los war. Ich schaute in ~/.config/google-chrome nach und fand Folgendes:
$ ls -i
...
3529523 'Local State'
3529523 'Local State'
...
Das ist dieselbe Datei mit demselben Inode, zweimal. Ich vermute, das könnte der Grund sein, warum Google Chrome verwirrt war, obwohl es zwischen jedem Neustart einwandfrei zu funktionieren scheint – es schreibt viel in diese Local\ State-Datei. Wenn ich es jedoch neu starte, sagt es, dass es den lokalen Status nicht laden kann. Weder SMART-Prüfungen noch btrfsck melden Fehler. Irgendwelche Ideen?
Antwort1
Ich habe das gleiche Problem mit btrfs und Kernel, 4.14.0aber meine duplizierte Datei war .config/google-chrome-unstable/Default/TransportSecurity. Ich konnte es beheben, indem ich
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/
Jetzt ls -l .config/google-chrome-unstable/Default.oldbekomme ich:
ls: cannot access '.config/google-chrome-unstable/Default.old/TransportSecurity': No such file or directory
total 0
-????????? ? ? ? ? ? TransportSecurity
An diesem Punkt habe ich im Einzelbenutzermodus neu gestartet und Folgendes ausgeführt:
umount /home
btrfs check --repair /dev/sdc1
Das beschädigte Verzeichnis wurde erkannt und repariert. Sie können möglicherweise einfach von dort aus beginnen, aber der Vollständigkeit halber lasse ich die anderen Schritte, die ich ausgeführt habe, stehen.