tracker-miner-fs-3 will keep finding DELETED trigger events on BTRFS subvolumes of a mounted FS
Referring to what was discussed in these threads one two.
According to @carlosg
This is indeed the same root issue with subvolumes, concretely the homedir and the Documents folder have the same inode as the root directories of their respective subvolumes:
unix::inode: 256
This makes the "stable content identifier" to be the same for your homedir than your Documents folder (
urn:fileid:2df7ed9e-0114-45ac-b09a-60584b7775ce:256
). This breaks Tracker uniqueness expectations and triggers a deletion of the indexed data from the Documents folder when indexing the homedir, and vice versa.
My fix at !427 (merged) only observes subvolumes that are also expressed in mtab/fstab through the
subvol
option (e.g.-o subvol=Documents
) to give files in the subvolume a different base identifier. It does not observe subvolumes only known to btrfs, this is partly why the fix didn't do anything for your case (The other part being that your filesystem gets a UUID, which I did not handle for btrfs)
Reading some relevant tibdits of the BTRFS documentation, it seems they realized their creative usage of inodes may pose a tiny problem to decades of assumptions from userspace:
Inode number is not a filesystem-wide unique identifier, some applications assume that. Please use pair subvolumeid:inodenumber for that purpose.
Which at least might sound like a plan, with the tiny caveat that all their ioctls except one are constrained to CAP_SYS_ADMIN, and it does not return the subvolume ID. This ioctl (BTRFS_IOC_INO_LOOKUP_USER) seems to fill in subvolume name though. Maybe I can work with that.
===
Seems to be an edge case which could be quite common in some circumstances.