| Summary: | Summary: Tag and Tag Folder Papercuts | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-baloo | Reporter: | tagwerk19 |
| Component: | general | Assignee: | baloo-bugs-null |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | 4wy78uwh |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Case 1...
Baloo needs to be running and indexing the folders you are using. Baloo can be disabled,
failing, ignoring temporarily mounted or remote devices or not configured to index
particular folders. There are various bugs here, for example Bug 424871, Bug 435315,
Bug 441068
You might be thinking Baloo is indexing a folder whereas it is not, a common cause of this
being folders mounted elsewhere with a symlink. Baloo has a policy of not following
symlinks when indexing (see the Summary Bug 447119)
Note that if you add a tag through Dolphin, you are adding a file attribute (xattr), not
modifying the file itself.
If Baloo is running, you will see the tag appear in Dolphin's "Places" section (you may need
to force a refresh to see it, see below). You do not need to configure Baloo to do "Content
indexing" to get this info.
Similarly if you have tagged files in the past and disabled Baloo, it's possible to remove the
tag but the "tag folders" do not follow the change (Bug 414684)
... 1a
If Baloo is busy, it queues actions to add/remove tags (Bug 407530).
In this context, "busy" implies catching up with new files or dealing with deletions (deleting a
large number of files can generate a lot of work, Bug 442453). The background activity of
Context Indexing does not necessarily block metadata/tag updates.
... 1b
Baloo with remote storage is a separate issue - or collection of issues dependent on the
protocol (Samba, NFS or ??) and the capabilities of the remote filesystem.
Baloo deliberately avoids trying to index remote filesystems and this may impact both file
attribute (xattr) tags and embedded (EXIF/ID3) tags.
Case 2...
There exist different UI's and dialogs for managing tags:
You can view and navigate "tag folders" in a very similar way as filesystem folders
(go to "Places", open "All Tags" and click on the folders listed there). These folders are
dynamic and given to Dolphin by Baloo - if you add a tag to a file, Baloo sees the change,
indexes the information and presents it to Dolphin.
You can see and update tags if you open the properties of a file.
You can right click on a file, get a drop down menu and select "Assign Tags".
You can open the information panel in Dolphin with F11 and select one or a collection
of files.
You might be pushed to use one UI (and not the others) when wanting to do something specific:
If you want to remove a tag from a collection of files, your only option is to show the
information panel (F11), highlight the files and edit the tags though "Edit..." in the
info panel (See 431093, https://bugs.kde.org/show_bug.cgi?id=431093#c5)
If you want to add a tag to several files (Bug 426940) you need to do it via the dialog in the
information panel or copying the multiple files across into an open "tag folder".
If you want to add multiple tags to one file (Bug 420116, Bug 450006), the only option
is the dialog in the information panel.
Case 3...
There are various papercuts, traps for the unwary and workrounds you probably
need to know to do things safely:
If are in a tag folder, highlight some files and press "del", you are deleting the files and
not removing the tags applied to the files. See Bug 431093
If you drag and drop files from one tag folder to another (and specify a "move"), you get
a "copy". See Bug 431053
Some common applications do not look for and retain the file attributes when modifying
the file, cf if you tag a JPG file and then rotate it in Gwenview, Gwenview saves the file
without saving the tags. See Bug 431146
Additionally it may be that trying to assign tags to a read-only file fails silently (Bug 416258,
this can be an issue with files copied "as read only" from some digital cameras)
You may silently lose tags when you copy to a filesystem that does not support xattr's (so
copying from ext4, BTRFS or NTFS to FAT or to a mounted remote filesystem).
This applies to file system (xattr) tags, embedded (EXIF, ID3) tags are copied as they are part of
the file. The indexing of remote filesystems is a separate issue (as per comment 1
and maybe Bug 418605)
Case 4...
Dolphin may not keep up when adding or modifying tags, this may be as:
Baloo does not see a change and update it's index (there were previously
issues based a "too low" iNotify value, fd.inotify.max_user_watches, see Bug 353874)
Dolphin relies its cached data and does not always refresh it when it should (Bug 244163,
Bug 387663, Bug 401019 and in the places panel Bug 406406). Sometimes an F5 is sufficient;
sometimes closing Dolphin and relaunching is needed (as can happen if you've just created
your first tag).
... 4a
Baloo can also see multiple copies of particular files (when inodes change or a disc is remounted
with a different device number).
This issue deserves a separate summary. It's often seen on BTRFS filesystems (with multiple
subvols) but is not specific to BTRFS, detailed here:
https://bugs.kde.org/show_bug.cgi?id=402154#c43
(In reply to tagwerk19 from comment #1) > ... 1b > Baloo with remote storage is a separate issue - or collection of issues dependent on the > protocol (Samba, NFS or ??) and the capabilities of the remote filesystem. Detailed in Bug 452924 (In reply to tagwerk19 from comment #4) > Baloo does not see a change and update it's index (there were previously > issues based a "too low" iNotify value, fd.inotify.max_user_watches, see Bug 353874) Should be: Baloo does not see a change and update it's index (there were previously issues based a "too low" iNotify value, fs.inotify.max_user_watches, see https://bugs.kde.org/show_bug.cgi?id=433204#c1) (In reply to tagwerk19 from comment #4) > ... 4a > > Baloo can also see multiple copies of particular files (when inodes > change or a disc is remounted with a different device number). This has been fixed, here for KF6 https://invent.kde.org/frameworks/baloo/-/merge_requests/131 and cherrypicked for KF5 https://invent.kde.org/frameworks/baloo/-/merge_requests/169 but worth being aware of Bug 475919: you may prefer a "final" reindex. |
SUMMARY: A review of Dolphin/Baloo issues with tags and tag folders. These are generally minor things but with the prospect of being annoying, forcing workrounds or different workflows. These things that are often labelled "Papercuts". The aim of this bug it to provide a summary that can be referred to with new tag/tag folder bugs. ISSUES: Reports can however be grouped in four areas: A dependency on baloo and tripping up when dealing with non-indexed folders (including remote storage), collected under Comment 1 Multiple ways of doing something, complexity and necessary workrounds; collected under Comment 2 Papercuts, traps for the unwary and different ways of losing data, see Comment 3 Caching and refreshing tag information, see Comment 4 There's also a problem of distinguishing between embedded tags (as are held within image and music files, EXIF and ID3 data) and file attributes (that are "about" a file in the same way as a "Last modified date" is "about" a file). This summary is written in the context of someone trying to organise their files and discovering there's no "right place" to store something. A file, except if using hard and symbolic links, lives in one folder. Tags give the option to place a file in several folders - or "tag folders". The summary is in the context of navigating your data through Dolphin which provides a magnificent and mostly seamless interface to tagged information.