After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 485665 - files are copied to a local directory before being extracted
files are copied to a local directory before being extracted
Status: RESOLVED OBSOLETE
Product: file-roller
Classification: Applications
Component: general
2.20.x
Other Linux
: Normal normal
: ---
Assigned To: file-roller-maint
file-roller-maint
: 545472 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-10-11 09:13 UTC by Sebastien Bacher
Modified: 2020-11-11 19:15 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Sebastien Bacher 2007-10-11 09:13:31 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/146206

"...
gutsy, file-roller 2.20.0-0ubuntu1
this is big a problem, and I don't really understand why this has been done in this way

before extracting files, file roller copies the archive in a local directory. If the space on the device is low, you cannot extract anything and this error is given to you:
cp: write of `/home/yelo3/.fr-kw21if/lunar-1.6.2-beta1-i686.iso.bz2': No device space left

file-roller should be able to extract the archive from the position it has!
...
I've tested that this does not happen with zip, iso, rar files.
file-roller runs:
yelo3 16709 11.2 0.1 2136 736 ? S 18:34 0:05 unzip
-d /home/yelo3/Scaricati/iso -o -P /home/yelo3/Scaricati/iso.zip

but you can easily check this trying to un-gzip(bzip2) a big file (a
file that gunzips(bunzips2) in more than a few seconds)
while extracting it you can do a ps -ux and you will see:

yelo3 16982 11.5 0.0 2040 496 ? R 18:37 0:04 gzip
-f -d -n /home/yelo3/.fr-65rcKi/file.gz

or

yelo3 19326 18.1 0.7 5284 4024 ? D 18:49 0:02 bzip2
-f -d /home/yelo3/.fr-80UAsI/file.bz2
..."
Comment 1 Ahmad Syukri 2010-01-28 20:55:51 UTC
I've also commented on the Launchpad about why the implementation exists.

By the way, just I have said over there, I suggest moving the uncompressed file instead of copying it, so that no unnecessary duplication is made for destination with the same drive as the temp. Or is there any other technical reason for using cp?
Comment 2 Paolo Bacchilega 2010-01-29 09:08:10 UTC
if the destination folder already exists mv doesn't work correctly. (more details in bug #590027)
Comment 3 Ahmad Syukri 2010-01-30 00:39:46 UTC
Oh I forgot to mention that my suggested solution should apply to single compressed file, and not tarball. That way, no problem if you move it, no?
Comment 4 xgdgsc 2014-06-14 12:31:49 UTC
Has this get any progress in the few years? I' m experiencing a copy of 17GB file on the second drive to ~/.cache and compress to gz and copy back. This is just insane, and will hurt my SSD mounting /home.
Comment 5 David King 2016-05-04 10:49:23 UTC
*** Bug 545472 has been marked as a duplicate of this bug. ***
Comment 6 André Klapper 2020-11-11 19:15:14 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use file-roller and if you still see this bug / want this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/file-roller/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (volunteer workforce and time is limited).