Bug 475278 - Data loss on compressed files when another compression are happening
Summary: Data loss on compressed files when another compression are happening
Status: REPORTED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 22.12.3
Platform: Debian unstable Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-10-06 12:49 UTC by Kokan
Modified: 2023-10-06 14:09 UTC (History)
2 users (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 Kokan 2023-10-06 12:49:34 UTC
SUMMARY
If another compression is started while first one is ongoing, both compression stop abruptly.


STEPS TO REPRODUCE
1. Open Dolphin with 2 large directories (with lot of files)
2. Enter first directory, select all files, right-click and do "Compress as Archive.tar.gz"
3. First compression is started, it can be seen in bottom right corner, it is ongoing
4. While it is happening, go to other directory with same Doplhin instance, select all files there, right-click and do "Compress as Archive.tar.gz"

OBSERVED RESULT

Both compression stop when second is started with status "Finished". All files are present in archive, but they are 0 bytes. User never notice compression errored and, what is worse, archives are present, but empty!

EXPECTED RESULT

Both archive are created in parallel and are not empty.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma:  Debian testing
(available in About System)
KDE Plasma Version: 5.27.7
KDE Frameworks Version: 5.107.0
Qt Version: 5.15.10

ADDITIONAL INFORMATION

Do note that "Compress as zip" also stops compression, but I don't see .zip files produced. I can repro it with using two tabs. I cannot repro it with two dolphin windows. I also cannot repro it if I just compress folder (right-click on folder), just when compressing files.

Looks similar to https://bugs.kde.org/show_bug.cgi?id=474672, but this case is when running multiple compressions (maybe same underlying cause, not sure)