5

Okay, some time ago I found what seems to be a bug in nautilus.

/tmp$ mkdir test/
/tmp$ mkdir test2/
/tmp$ echo "very important stuff" > test/important-file.txt
/tmp$ ln -s /tmp/test/ test2/test

If you try to mv test2/test . bash is smart enough to answer : 

mv: «test2/test» and «./test» identify the same file

I created a symbolic link to test (a directory containing a file) in another location, and then I moved the symbolic link to the place where the directory was

But then , nautilus gets into the game:

Moving symbolic link to the location where de directory is in nautilus

Nautilus understands that the symbolic link is a directory, and it kindly offers me to merge them:

enter image description here

Now, I merged them (I obviously thought it was two different directories). And as a result...

tmp$ ls -la
lrwxrwxrwx  1 cool-user  best-group-ever      9 août  26 23:51 test -> /tmp/test

Okay. So I lost my directory (which is normal, because I overwrote it) and ended up with a useless circular symbolic link, but... what happened with my important-file.txt ? It had an inode, that's not referenced by any directory in my system anymore.

Obviously, I didn't write that inode in a post-it... so, where is it ?. Is there any way to find every file with an inode which is not referenced by any dir?

And as a bonus question: Is this the expecteb behaviour of nautilus, or is it a bug?

Why and how this happened to me is a long story, but I had some really important (and confidential) files within my directory that I would like to get back

Luis Sieira
  • 101
  • 8
  • 1
    You probably have an excessive cd command on line 4 of the snippet – kos Sep 18 '15 at 10:02
  • 3
    However it's definetly a bug, and I've got the feeling that the file will be gone after this. Here's the post of an user reporting the same thing on Launchpad, in a bug report probably related to the same "main" Nautilus' internal issue – kos Sep 18 '15 at 10:56
  • It seems to be easy if important-file.txt is still opened by another process, so you can find out the inode by listing all open files (lsof | grep important-file.txt) and then re-link it. See http://serverfault.com/questions/168909/relinking-a-deleted-file and http://www.barricane.com/undelete-open-file-from-inode - but I guess your file is not opened any more, so it could also probably be overwritten already... – Byte Commander Sep 18 '15 at 11:56
  • Besides that, you can look for the standard data recovery methods of deleted files. Make sure you don't boot from or writeable mount the disk any more though! http://superuser.com/q/170857/418736 or http://askubuntu.com/questions/217606/undelete-files-on-ext4 or http://askubuntu.com/questions/41601/is-there-any-recovery-software-available-for-ext4 - GOOD LUCK! :-) – Byte Commander Sep 18 '15 at 12:06
  • Well, I tried at the time without succeeding, but it was long ago. Actually, that's why I thought the file hadn't been deleted, as his inode should still be listed by the device, but not referenced anywhere. Those utilities do the opposite, the look for file data that's not referenced by an active inode. – Luis Sieira Sep 18 '15 at 12:17

2 Answers2

3

Not sure that's possible. After all, all your of your free space is a list of inodes.

See however the Orphan File feature of ext4.

Serban Murariu
  • 56
  • This sounds really interesting, could you link something about what free space is ? Is it always the case for Unix systems ? – Luis Sieira Sep 18 '15 at 12:11
  • If you can point me to some documentation detailing that; the bounty is yours :-) – Luis Sieira Sep 19 '15 at 19:52
  • 1
    ext2/3/4 all use broadly the same approach to storing files. As Serban says, free space is a list of inodes. If a file is actually deleted. the chain of inodes that were the file, join the list of inodes that are free space. If the disk gets corrupted, such that the inodes are neither in a file, or free space, then after running fsck they will (or at least used to) appear in the lost+found folder in the root of the mounted filesystem (so /usr/lost+found if you mounted /usr or /lost+found, for the / mount point) – sibaz Sep 23 '15 at 16:29
0

I'll post my answer, but I'm not accepting it, since it doesn't seem to be by any meanings a good one (at least in terms of efficiency or completeness).

This would require a program (I'd write it in C) that recursivelly walks the entire directory tree, registers every referencied inode in an ordered list (avoiding duplicates), and then diffs it against the actual inode list.

The difference are the missing files

Luis Sieira
  • 101
  • 8
  • unfortunately unreferenced inode = deleted. So it comes down to undelete files. –  Sep 19 '15 at 16:59
  • I knew deleting a file in use could leave orphan inodes hanging around, but I didn't know that a file was considered as deleted if it's inode was not referenced by any directory... Do you know about any documentation concerning that? – Luis Sieira Sep 19 '15 at 19:51
  • 2
    Check unlink system call manual page (man 2 unlink). Anyway - found the source of the problem. Conflict dialog sees the source as a folder and presents the option to merge, but the code responsible for performing the copy/move sees it as a file. Also merge internaly = overwrite. So by clicking merge, target folder is removed recursively (using remove_target_recursively) and the new file takes it's place. This is the case for every link to a folder. i.e. every link to folder named 'test' will overwrite any folder named 'test'. –  Sep 20 '15 at 11:48
  • @adonis Can you post that as an answer so I can reward you the bounty? – Luis Sieira Sep 20 '15 at 18:51
  • I'm glad that my comment was helpful to you, but I don't see how this answers your question - "How to find files whose inode is not referenced by any directory" –  Sep 21 '15 at 12:19
  • It answers it by stating that it is not possible, in addition with @Serban's answer it makes a complete answer – Luis Sieira Sep 21 '15 at 14:50
  • It's worth clarifying, that while adonis is right in explaining how the 'merge' works, an unreferenced inode != deleted. unreferenced inodes, are a sign of corruption and will be picked up by fsck and added as files or directories in lost+found. As discussed earlier, legitimated deleted inodes are added to the free space list, and will be re-used (over written). – sibaz Sep 23 '15 at 16:32
  • 1
    There is an existing program (written in C) that recursively walks the entire filesystem, registers every referencied inode in an ordered list (avoiding duplicates), and then diffs it against the actual inode list.

    It's called fsck and leaves the orphaned inodes in a directory called lost+found.

     – Stephen M. Webb Sep 24 '15 at 10:34