If an iso file path contains a symlink, the kio_iso module fails to open it claiming that the file doesn't exists. See Bug#344460
Description
Details
- Differential Revisions
- D2603: Add advanced debugging to KIso
Related Objects
- Mentioned In
- T3479: Krusader freezes when renaming a file that is inside an archive
- Mentioned Here
- D2603: Add advanced debugging to KIso
I've found two possible solutions:
- rewrite the QUrl pointing to the iso file with its absolute path (using QFileInfo::canonicalFilePath()); this leads to a problem: once entered the iso file, the panel path is changed to the symlinked path, example : with this symlink cd work && ln -s ~/../software isos I enter in isos/ directory and browse a iso file; when I exit the file, I'm in ~/software and not in ~/work/isos
- port the kio_krarc debugger to kio_iso and rewrite the module to recognize symlinked paths.
I've looked that with katepart krusader uses the first solution, when we open a symlinked file, the canonicalpath is passed to kate; but this not involves panel paths...
Maybe this issue has something to do with that bug:
After entering and exiting an iso file: broken symlinks are not made prominent https://bugs.kde.org/show_bug.cgi?id=367707
Anyway if someone is solving one issue perhaps is able to solve the other one, reusing his knowledge.
Using D2603, I was able to find where to problem is:
the path passed to KIso::KIso is wrong (incomplete), it doesn't contains nothing after the symlink.
Configuration test:
~/software where I have all my isos
cd ~/work/ && ln -s ../software iso
I can't browse any iso from /home/davide/work/iso. Trace:
Pid:17267 ┏KIso(109) Pid:17267 KIso(110): Starting KIso: /home/davide/work/iso - type: Pid:17267 ┏prepareDevice(163) Pid:17267 prepareDevice(164): Preparing: /home/davide/work/iso - type: inode/directory - using the force: 0 Pid:17267 ┗prepareDevice Pid:17267 ┗KIso
If I create an absolute symlink
cd ~/work/ && ln -s /home/davide/software iso
all work fine. Trace:
Pid:6102 ┏KIso(109) Pid:6102 KIso(110): Starting KIso: /home/davide/work/isos/gparted-live-0.26.1-5-i686-pae.iso - type: Pid:6102 ┏prepareDevice(163) Pid:6102 prepareDevice(164): Preparing: /home/davide/work/isos/gparted-live-0.26.1-5-i686-pae.iso - type: text/plain - using the force: 0 Pid:6102 ┗prepareDevice Pid:6102 ┗KIso
Using
cd ~/work/ && ln -s ~/software iso
works to as it produces an absolute symlink.
The problem is not inside KIso, we have to change the way how Krusader passes the symlink paths to KIO.
A fix could be to change in krusader/Panel/panelfunc.cpp:215
from
url.setPath(QDir::cleanPath(url.path()));
to
url.setPath(QDir(url.path()).canonicalPath());
obviously only when url should involve kio_iso; but I don't really like it: you can successfully browse the iso file, but when you exit, you are in the directory targeted by the symlink, not the one where you entered the iso.
Does anyone know how to KIO slavebase works? (to avoid debug/read all kio code)