0

Does Btrfs provide any method to identify a file other than its path? I mean, if there was a file /my/directory/a.txt and if someone or something moved it to /my/other/directory/b.txt, it is still the same file, but since the path has been changed, I would have no way to know if the "b.txt" was "a.txt".

Damn Vegetables
  • 1,377

2 Answers2

1

There are inode numbers (see ls -i, stat), like in many (all?) other *nix filesystems. In Btrfs they are stable (they don't change after reboot, they don't change if you mount in another machine), but unique only inside a subvolume (not inside an entire filesystem1); and they can be reused.

Two paths reporting the same inode number at the same time inside the same subvolume lead to the same file; this is how hardlinks work. But in general you cannot be sure if today's inode number N is the same file as yesterday's N.

Keeping a hardlink in a directory nobody can access may be a workaround; because as long as the hardlink exists, its inode number cannot be reused inside the same subvolume. Then you can list all files with the same inode number on demand.

Still there are scenarios when you cannot track the file because in the new location it's formally a different file. These include:

  • When the original is "moved" by being copied+deleted (regardless if CoW-copy or not).
  • When the original is moved to another subvolume.
  • When the original is moved to another filesystem (this is copy+delete really).

1 Note two different subvolumes mean two different device numbers, even if they are accessible under a single mountpoint (where their (grand-…-)parent subvolume is mounted). This is how Btrfs works.

Kamil Maciorowski
  • 21,864
  • "inode ... unique only inside a subvolume (not inside an entire filesystem);" I think that needs more details. Do you mean that you can mount a single btrfs file system on some mount point (eg. on /mnt/foo) and have two different files with same device id and inode, if they're on separate "subvolumes"? –  Oct 12 '20 at 08:02
  • @user414777 No. Two different subvolumes mean two different device numbers, even if they are under a single mountpoint. – Kamil Maciorowski Oct 12 '20 at 08:12
  • Interesting. Btrfs apparently allocates device numbers dynamically for its subvolumes, including for the top one. The device number of a file does not correspond to the actual block device in any way, and may be different, depending on the order in which btrfs fileystems were mounted. –  Oct 12 '20 at 09:12
1

I'd say that you should create a hard link to that file eg. with

ln -L /path/to/a.txt /unique/path/in/the/same/fs

If that succeeds, you will still be able to access the file even if it was renamed or removed.

I'm not aware of any way to create a "weak" hard link (a hard link which would automatically removed when all the other hard links to the file are removed).

  • No, I cannot use link, because this question was mainly about my reorganising the file/directory structure. I would like to know which files are moved to where to copy only new files, not moved/renamed files when doing back-up (not using existing back-up software, because of my complex situation). – Damn Vegetables Oct 13 '20 at 00:10
  • 1
    @DamnVegetables sounds like using the birth/creation time would be a better option. Not inode numbers, which can be reused. But it's really not clear what your trying to do -- reinvent rsync? –  Oct 13 '20 at 04:42
  • I did not get notification for this comment. Weird. I'm not sure how rsync works but, I don't have a large back up drive but small hard drives. And I don't want to connect all of them each time I back up. So, basically, I want to copy only changed files to one last small drive. And I want to keep track of which files are where, so that in case the big disk dies, I could reconstruct it from the backed-up files spread on the multiple small disks. I thought that kind of requirement is complicated, so I thought of writing my own programme for that. – Damn Vegetables Oct 16 '20 at 06:19