Bug 499400 - Dolphin emits a system log message for every file moved across file systems
Summary: Dolphin emits a system log message for every file moved across file systems
Status: RESOLVED INTENTIONAL
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 24.12.1
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-02-01 21:42 UTC by Schlaefer
Modified: 2025-02-02 17:36 UTC (History)
2 users (show)

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


Attachments
dolphin file operation logged in system log (1.82 MB, video/x-matroska)
2025-02-01 21:42 UTC, Schlaefer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Schlaefer 2025-02-01 21:42:26 UTC
Created attachment 177893 [details]
dolphin file operation logged in system log

SUMMARY

For every file copied or moved across a file system border (tested here with btrfs from/to xfs or btrfs subvolume to btrfs subvolume) a message is created in the system log including the full transactions paths.

STEPS TO REPRODUCE

1. E.g. on btrfs create a subvolume A and a subvolume B
2. Touch a new file on subvolumeA
2. Move that file from subvolume A to subvolume B

See also attached example video

OBSERVED RESULT

A log entry is generated:  dolphin[]: kf.kio.workers.file: copy() QUrl("<source parh>) to QUrl("<target path>") mode= 420

EXPECTED RESULT

Dolphin should not emit a message for every copied file. 

Copying a lot of files in 100+ or worst case 10k+ range completely floods the system log making it very hard to use.

While rather abstract there is an argument leaking meta information. E.g. a user can move a file to the trash and delete it, but on btrfs this still move the file across subvolumes logging it.

SOFTWARE/OS VERSIONS
Operating System: CachyOS Linux 
KDE Plasma Version: 6.2.5
KDE Frameworks Version: 6.10.0
Qt Version: 6.8.1

ADDITIONAL INFORMATION
Comment 1 fanzhuyifan 2025-02-01 21:59:33 UTC
The severity of this log entry is debug[0]. If you don't want to see this, you can turn up your log level (e.g., to warning or notice).

[0] https://invent.kde.org/frameworks/kio/-/blob/37f80017771cad864309cac1d06d34de6acc310c/src/kioworkers/file/file_unix.cpp#L540
Comment 2 Schlaefer 2025-02-01 23:12:19 UTC
I still feel that while intentional is an unfortunate situation. This is not only about filtering items out on viewing, but also storing them in the first place - at least in the default systemd config. Other points aside, the current behavior has a considerable impact on the system journal as a shared resource by blowing it up in size or rotating out information from other sources.
Comment 3 fanzhuyifan 2025-02-02 15:47:55 UTC
(In reply to Schlaefer from comment #2)
> I still feel that while intentional is an unfortunate situation. This is not
> only about filtering items out on viewing, but also storing them in the
> first place - at least in the default systemd config. Other points aside,
> the current behavior has a considerable impact on the system journal as a
> shared resource by blowing it up in size or rotating out information from
> other sources.

By default debug messages are not even generated on normal systems. Do you have a modified QT_LOGGING_RULES env variable that is enabling debug output?
Comment 4 Schlaefer 2025-02-02 17:36:03 UTC
(In reply to fanzhuyifan from comment #3)
> have a modified QT_LOGGING_RULES env variable that is enabling debug output?

Not that I know of. I'm running CachyOS and tested in a fresh VM to be sure (now also tested vanilla Arch and EndeavourOS)

Apparently that's the Arch default and you have to disable it [1]. Haven't found where it is originally enabled.

Thanks for your patience. +1

[1] https://wiki.archlinux.org/title/Qt#Disable/Change_Qt_journal_logging_behaviour