5

I use btrfs with Linux 4.10.8. After a hard reboot, Google Chrome claimed it was not able to find the local data. Some of it came back as soon as I added the relevant user IDs, so I was curious what was going on. I looked in ~/.config/google-chrome, and found this:

$ ls -i 

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

That's the same file, with the same inode, twice. I'm guessing this might be why Google Chrome got confused, although it seems to work fine between every restart – writing a lot to this Local\ State file. When I restart it, however, it says it's unable to load the local state. Neither SMART checks nor btrfsck reports any errors. Any ideas?

  • touch a; ln a b will get you two files with same inode, but different names (not really two files, just two names). – ctrl-alt-delor Apr 14 '17 at 22:24
  • There is not enough information, in the question. Can you add information to the question. What was the error message from google chorme? How did you add user IDs? What happened next? … – ctrl-alt-delor Apr 14 '17 at 22:26
  • I have the same, using BTRFS with kernel 4.11.0. Probably a BTRFS bug, I'll investigate and report. pastebin.com/bGPz6s96 – Mark K Cowan May 29 '17 at 19:54
2

I have the same problem on btrfs with kernel 4.14.0 but my duplicated file was .config/google-chrome-unstable/Default/TransportSecurity. I was able to fix it by doing

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/

Now when I ls -l .config/google-chrome-unstable/Default.old I get:

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

At this point I rebooted to single-user mode and ran:

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

It noticed the corrupted directory and repaired it. You may be able to just start from there, but I'm leaving the other steps I took for completeness.

  • It is filesystem problem, not a Linux feature. Either you have fs corruption (-> run fsck), or there is a btrfs bug (unlikely). – peterh Jan 1 '18 at 21:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.