[dolphin] [Bug 471099] Tags can't be renamed nor be deleted

[Dean Rikrik Ichsan Hakiki]

https://bugs.kde.org/show_bug.cgi?id=471099

--- Comment #6 from Dean Rikrik Ichsan Hakiki <deanrikrikichsanhakiki+kdebug at gmail.com> ---
(In reply to tagwerk19 from comment #5)
> > ... sorry if somehow I make this bug report section like a forum discussion and break any guidelines ...
> First off, no worries. The perception and description of a bug grows and
> changes with time. That should be expected...
> 
> > ... but baloo doesn't seem to detect this changes and stays at "Idle" on the `balooctl monitor` command ...
> If you were doing "content indexing" and editing a file (that might happen
> if you were changing embedded tags in an MP3 or JPG), then baloo would need
> to open the file, read the metadata and index it.
> 
> With 'xattr', the info is "filesystem metadata", akin to the file
> modification time. Baloo just picks this up and you won't see the file
> appearing in "balooctl monitor". The good news is that you can make use of
> tags even if you are not doing content indexing...
> 
> What does "balooshow -x your-tagged-file.txt" give you? Do you get any
> (some? all?) details?

When I try the command `balooshow -x /path/to/my/file.extension` it shows
something like this

`36acae10000002d 45 57330401 /path/to/my/file.extension: No index information
found`

But the getfattr returns the applied tags just fine.

And I think I found out why, for some reason, even though Baloo didn't do
anything, idling, with the indexing progress at 100%, it just becomes
unresponsive, it happened for the first 2 purges and restart attempts, and to
note that at the time only my home folder being indexed and the hidden
folder/file is **unchecked**. What I also found is `balooctl monitor` works
just fine but something like `balooctl status` took quite a long time to return
the result, and opening the `Search` settings on the KDE System settings took
around the same time before showing up the page, and the status is Idle at 100%
indexed while executing `balooctl disable` only says disabling and stopping the
baloo but seems failed to do so, and with the apparent result when I do
`balooctl purge` because it is waiting for the baloo to stop, but at the end of
the wait it says failed to stop baloo. But after that, I do some purge and
restart cycles again and it seems Baloo is well-behaved now, so maybe the
actual bug was Baloo sometimes can become unresponsive and it persist across
restarts.

-- 
You are receiving this mail because:
You are on the CC list for the bug.