https://bugs.kde.org/show_bug.cgi?id=402154
--- Comment #31 from tagwer...@innerjoin.org ---
(In reply to Joachim Wagner from comment #29)
> An alternative to relying on UUIDs and sub-volume IDs is to assume mount
> points of filesystems do not change and to proceed as follows...
Apologies, I fear you'll have to step through your process for me. I'm somehow
missing something...
If I look on Tumbleweed I can see results from:
stat testfile
stat -f testfile
findmnt -nT testfile
These give me the major/minor device numbers + inode of the testfile, the
"filesystem ID" and mount point (with BTRFS subvol/subvolid).
The minor device number jumps around with reboots. The filesystem ID, subvol
and subvolid seem solid. Snippets of my last reboots and updates:
Device: 0,40 Inode: 2506
ID: cef844b93a5a00ff
BTRFS: subvolid=263,subvol=/@/home
Device: 0,39 Inode: 2506
ID: cef844b93a5a00ff
BTRFS: subvolid=263,subvol=/@/home
Device: 0,46 Inode: 2506
ID: cef844b93a5a00ff
BTRFS: subvolid=263,subvol=/@/home
Device: 0,40 Inode: 2506
ID: cef844b93a5a00ff
BTRFS: subvolid=263,subvol=/@/home
Device: 0,41 Inode: 2506
ID: cef844b93a5a00ff
BTRFS: subvolid=263,subvol=/@/home
Device: 0,43 Inode: 2506
ID: cef844b93a5a00ff
BTRFS: subvolid=263,subvol=/@/home
At the moment, with every reboot, baloo indexes or reindexes the testfile
"under" it's new docID (device number/inode) and over time, it gathers quite a
collection of entries:
baloosearch -i testfile
9ca00000027 /home/test/testfile
9ca0000002f /home/test/testfile
9ca0000002e /home/test/testfile
9ca0000002d /home/test/testfile
9ca0000002c /home/test/testfile
9ca0000002b /home/test/testfile
9ca0000002a /home/test/testfile
9ca00000029 /home/test/testfile
9ca00000028 /home/test/testfile
The mapping would have to work when indexing (going from full filename to an
invariant, unique, internal docID) and when searching (going from the docID to
the canonical filename).
--
You are receiving this mail because:
You are watching all bug changes.
