Bug 438527 - `balooctl clear` always prints "File(s) cleared" and never prints "File not found on filesystem or in DB"
Summary: `balooctl clear` always prints "File(s) cleared" and never prints "File not f...
Status: RESOLVED FIXED
Alias: None
Product: frameworks-baloo
Classification: Frameworks and Libraries
Component: balooctl (show other bugs)
Version: 5.82.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: baloo-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-13 00:03 UTC by skierpage
Modified: 2024-07-03 06:27 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description skierpage 2021-06-13 00:03:56 UTC
SUMMARY
balooctl clear's logic seems wrong. If you clear a file that has never existed, it prints "File(s) cleared" and never triggers its code that prints "File not found on filesystem or in DB"

STEPS TO REPRODUCE
1. Enter `balooctl clear /never/had/this/file`
2. Enter `ls -lt $HOME/.local/share/baloo/index`
3. Look at baloo source code

OBSERVED RESULT
balooctl prints
  Could not stat file: /never/had/this/file
  File(s) cleared
The modification time of Baloo's index doesn't change.

EXPECTED RESULT
balooctl clear has code to print "File not found on filesystem or in DB" but it doesn't run.
balooctl should print "NN file(s) cleared" where NN is the count of files balooctl tried to clear from the index.

SOFTWARE/OS VERSIONS

Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 5.21.5
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2 on Wayland

ADDITIONAL INFORMATION
The "clear" handling in https://invent.kde.org/frameworks/baloo/-/blob/master/src/tools/balooctl/main.cpp (which seems more recent than Fedora 34's package)
* assumes filePathToId() returning 0 means failure, but as I understand it the underlying stat64() call returns 0 on _success_! -1 means error.
* always calls tr.removeDocument(id) for each argument even if it didn't locate an id.
* always prints "File(s) cleared".
Baloo's removeDocument() doesn't return a status, so it seems impossible to detect successful clearing.

It would also be nice to print the ID (as shown by balooshow and baloosearch --id) of each file that was cleared in baloo's index, because of bug 438382 and similar. So the ideal output from
  % balooctl clear /never/had/this/file /path/to/file2 /now/gone/file3
would be
  File /never/had/this/file not found in filesystem or in index.
  Clearing /path/to/file2 with ID 5be2000000803 from index.
  File /now/gone/file3 with ID 3fef80000fd03 not found in filesystem, clearing from index.
  2 file(s) cleared from Baloo's index.
Comment 1 tagwerk19 2021-06-13 06:42:41 UTC
(In reply to skierpage from comment #0)
> ... baloosearch --id
Every day a learning day! That's rather useful :-)

Yes, I see the same behaviour with "balooctl clear...".

Can flag as Confirmed...
Comment 2 skierpage 2021-06-13 10:22:46 UTC
(In reply to skierpage from comment #0)

> balooctl clear's logic seems wrong. If you clear a file that has never
> existed, it prints "File(s) cleared" and never triggers its code that prints
> "File not found on filesystem or in DB"

This was fixed after 5.82.0, ignore my faulty analysis. The reporting could still be clearer.
Comment 3 tagwerk19 2021-06-13 11:31:31 UTC
What I see on "Unstable" (Frameworks 5.84.0)

If the file exists and is indexed or exists but is not indexed, "balooctl clear..." gives:

    $ balooctl clear file1.txt
    Clearing /home/test/file1.txt
    File(s) cleared

If the file doesn't exist and is not indexed:

    $ balooctl clear file2.txt 
    File not found on filesystem or in DB: /home/test/file2.txt
    File(s) cleared

If the file doesn't exist but had been indexed:

    $ balooctl clear file3.txt 
    File has been deleted, clearing from DB: /home/test/file3.txt
    File(s) cleared

Note to self: Don't assume things haven't been fixed when you weren't looking 8-}

You can flag "Resolved" if you wish or leave as is...
Comment 4 tagwerk19 2024-07-03 06:27:36 UTC
(In reply to skierpage from comment #2)
> ... This was fixed after 5.82.0, ignore my faulty analysis. The reporting could
> still be clearer ...
I'm a bit slow at closing things....