ib
Drag & Drop Extracting
- Support target folder names with spaces
- Support extracting files, folders with spaces in their name
Please describe the steps leading to problems in detail, specifying the software involved, its versions and your distribution as issue. I cannot reproduce.
Thank you. Below some details.
This is a Genoo box with following related software and libraries:
$ equery l gcc xfce4-session binutils openrc glib
* Searching for gcc ...
[IP-] [ ] sys-devel/gcc-11.3.0:11
* Searching for xfce4-session ...
[IP-] [ ] xfce-base/xfce4-session-4.16.0:0
* Searching for binutils ...
[IP-] [ ] sys-devel/binutils-2.37_p1-r2:2.37
* Searching for openrc ...
[IP-] [ ] sys-apps/openrc-0.44.10:0
* Searching for glib ...
[IP-] [ ] dev-libs/glib-2.72.2:2
Issue is present both on master branch of this repo (commit: 63dad3ceb7a3d1dc2288a0df6b054a6ea244a8b6) and app-arch/xarchiver-0.5.4.18 provided by Gentoo portage.
Two main issues when extracting from a zip archive:
1. Dragging a file with a space / spaces in its name
I open a zip archive which contains a folder with name of "f f f f f" and drag to destination. I get error with this information:
Command: sh -c "exec mv -n -- `ls -A` '/home/antti/temp/archtest'"
mv: cannot stat 'f': No such file or directory
mv: cannot stat 'f': No such file or directory
mv: cannot stat 'f': No such file or directory
mv: cannot stat 'f': No such file or directory
mv: cannot stat 'f': No such file or directory
2. Dragging file(s) to destination folder with a space character in it's name
Trying to drag files from zip archive while the destination path has folder names with a space present. Error gives following information:
Command: sh -c "exec mv -n -- `ls -A` '/home/antti/temp/archive\ test'"
mv: target '/home/antti/temp/archive\ test' is not a directory
In this case, if I drag a single file only, we'll end up with a file /home/antti/temp/archive\ test. So archive\ test being the new filename of the original file in the zip.
The patch I provided fixes both of the detailed anomalies.
Perhaps we also should consider using full paths when calling external binaries? Otherwise it's rather trivial to have "what ever" running instead of the desired command (for example if users PATH has been tampered with)?
What program is your drop target?
Perhaps we also should consider using full paths when calling external binaries?
I will consider this.
Could you please give the attached patches from my local repository a try (against current master).
Applied three patches..
c994f3e6e1b1af4599d34147139e9012e3941e35c496ca7d6c7eddf8e1b09d14 0006.patch
afc81a8e933d888c455e3da41824f999f95a93bfb83a5abdd105b9512a94c062 0008.patch
868084b35c38bde863c83f0abd41ec49b315acce087ba17beb728dd10364ba2c 0009.patch
.. on top of 63dad3ceb7a3d1dc2288a0df6b054a6ea244a8b6.
Could not reproduce either one of the issues with the newly compiled executable. Looks good!