https://bugs.kde.org/show_bug.cgi?id=526854
Bug ID: 526854
Summary: Compress and extract jobs depend on the process-wide
working directory (QDir::setCurrent) and fail inside
Dolphin when it changes
Classification: Applications
Product: ark
Version First 26.08.1
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
SUMMARY
AddJob::doWork() (kerfuffle/jobs.cpp:721) calls QDir::setCurrent(globalWorkDir)
and passes paths relative to it to the plugins. The libzip plugin hands them to
zip_source_file(), and libzip opens them later in zip_close(). There are
similar calls in kerfuffle/cliinterface.cpp (93, 108, 158, 201, 788),
plugins/libarchive/libarchiveplugin.cpp (280) and
plugins/clizipplugin/cliplugin.cpp (206, 259); line numbers are from
release/26.08.
The Compress and Extract context menu actions run inside Dolphin's process.
Anything else in that process that changes the working directory during a job
makes the relative paths point somewhere else.
CASE 1: Dolphin's folder size counter (Dolphin bug 526853)
1. In Dolphin, set Configure Dolphin > View > Content Display > Folder size:
"Show size of contents".
2. In Details view, open a folder whose subfolders contain many files (here two
with about 45,000 and 50,000 entries) and that also contains a folder with
several GB of data.
3. Right-click the large folder > Compress > Compress to "<name>.zip".
After a few seconds the notification reports the job as finished, but no
archive exists (5 of 5 attempts; the false success is bug 526851). An
LD_PRELOAD shim around libzip logged (paths shortened):
zip_open(~/code/<folder>.zip, ZIP_CREATE) cwd=~/code -> ok
zip_file_add(<folder>/<file>) ... (relative paths)
zip_close() with 45225 entries cwd=~/code
zip_close() = -1: Can't open file: No such file or directory
zip_open(~/code/<folder>.zip, ZIP_RDONLY) cwd=~/code/<sibling>/tiles ->
NULL, error 9
The same job in a separate process (`ark --add --changetofirstpath
--autofilename zip <folder>`) created the complete archive in 3 of 3 runs.
CASE 2: two Ark jobs at the same time (not reproduced here)
Bug 519580 (filed against Dolphin): two compress jobs started from folders with
different parent directories both fail, the log shows "ark.libzip: Failed to
open archive. Code: 9", and no zip files are created; with the same parent
directory both succeed. That fits this cause, because with the same parent both
jobs set the same working directory. Bug 482271 (parallel "Extract here" puts
files into HOME) fits the extraction side (libarchiveplugin.cpp:280).
EXPECTED RESULT
Jobs neither depend on nor change the process working directory.
SUGGESTED FIX
Read the source files by absolute path and compute the entry names relative to
the base directory. In the libzip plugin, writeEntry() already keeps the source
path (zip_source_file) and the entry name (zip_file_add) apart. For the CLI
plugins, QProcess::setWorkingDirectory() sets the directory for the child
process only.
SOFTWARE/OS VERSIONS
Arch Linux, KDE Plasma 6.7.5, KDE Frameworks 6.30.0, Qt 6.11.2, Ark 26.08.1,
Dolphin 26.08.1, libzip 1.11.4
ADDITIONAL INFORMATION
Drafted with an AI assistant (Claude) from source reading, logs and tests on
the reporter's system.
--
You are receiving this mail because:
You are watching all bug changes.
