files are copied to a local directory before being extracted

Bug #146206 reported by Nicolò Chieffo on 2007-09-28
50
This bug affects 10 people
Affects Status Importance Assigned to Milestone
File Roller
Confirmed
Medium
file-roller (Ubuntu)
Medium
Ubuntu Desktop Bugs

Bug Description

Binary package hint: file-roller

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!

Sebastien Bacher (seb128) wrote :

Thank you for your bug. How do you extract the file? Does it happen with any format? I just tried with a zip and doesn't seem to happen

Changed in file-roller:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Incomplete

the file was a bz2. Does it happen with bz2 files for you?

Sebastien Bacher (seb128) wrote :

That's not easy to say since extracting most of bz2 is really quick and I've some disk space available

Nicolò Chieffo (yelo3) wrote :

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

Nicolò Chieffo (yelo3) wrote :

Sebastien, I also see this problem when creating the archives:
yelo3 19702 3.8 3.4 70412 17928 ? S 18:57 0:00
file-roller --default-dir=file:///home/yelo3/Scaricati --add
file:///home/yelo3/Scaricati/file
yelo3 19720 0.0 0.0 1752 488 ? S 18:57 0:00
/bin/sh -c cp -f -- file /home/yelo3/.fr-2JsrgK/file

the file I try to add to the archive is copied to my home directory first

I must say that the directory /home/yelo3/Scaricati/ (where I extract
files and where I get files to add to archives) is in a different
partition (ntfs-3g). Might this be the cause?

Sebastien Bacher (seb128) wrote :

that's likely because they are not on the same disks right, do you get the issue if you try the same actions in your user directory?

Nicolò Chieffo (yelo3) wrote :

well, actually yes... I created a bz2 in my home dir and when
decompressing it I see this process:
bzip2 -f -d /home/yelo3/.fr-7hqGCY/file.bz2

Nicolò Chieffo (yelo3) wrote :

you can try yourself with this file
it is 500MB of /dev/zero

Sebastien Bacher (seb128) wrote :
Changed in file-roller:
status: Incomplete → Triaged
Changed in fileroller:
status: Unknown → New
Nicolò Chieffo (yelo3) wrote :

Sebastien, did you manage to reproduce the problem?

Sebastien Bacher (seb128) wrote :

I didn't try, we receive too many bugs to work on everything. This one has enough details and seems to be an upstream issue so I just sent it to bugzilla since we don't have the ressources to work on it in an Ubuntu specific way now

The problem with bzip2 is that it has no information to its uncompressed size, unlike gzip. Assuming a scenario where destination may not have enough disk space left, if one wants to copy the content to the destination, here are the possible solutions:

1: (current implementation) Make a copy of the archive, decompress it, then try to copy it to destination, using cp. If it doesn't have enough space, cp will fail and return insufficient space error.
2: uncompress it directly to destination with bzcat2 (or bzip2 -d -f -c). It will uncompress until destination is full, at which point it fails and return insufficient space error. Delete the partially copied file.

Both solutions are not pretty, but from my experience solution 1 is better than solution 2. This is because, if you stuff up the destination drive during the extraction, you might cause disruption to other activity on the disk that might have succeeded if you didn't fill it up in the first place.

Of course, if it's going to be unpacked to the same drive, it's kind of silly to copy the uncompressed temp file instead of moving it. Otherwise, file-roller works as intended.

Changed in file-roller:
importance: Unknown → Medium

Ok, today I wanted to decompress a gziped .iso file from an external hard drive and was surprised when suddenly cp appeared in the gnome-system-monitor.

So, just to be sure the problem is adressed properly: File Roller is copying the 8 GB .gz file from my external hard drive to a folder in /home/user/.cache, then decompresses it to the destination of the file.
This happens when compressing and decompressing .gz, .bzip2, .xz, but not with tar.gz, tar.bzip2 and tar.xz. These are just the ones I tested, there could be more.

This could be a good feature, as Ahmad said 4 years ago, but it is not. This is just silly:

The gzip decompression is, in my case, as fast as the read speed of my external hard drive. It uses just 40% of one core on my system, so it is just limited by the copying speed. Now, when File Roller thinks it has to copy it twice, it takes twice the time it would have to.
But there is more: I had problems becouse of this years ago, when I had only a 60GB HDD, but I didn't know why at that time. Lets say, you have a 10GB partition image (.img) on your external hard drive, compressed with gzip (.img.gz) which is now 6GB, thanks to the magic of gzip. You want to decompress it to the HDD of your PC and you have 13 GB free, just right for the 10 GB decompressed file. But this is when File Roller pisses on your great calculation. It copys the 6GB file into your .cache directory and suddenly there are only 7GB left on your system and File Roller fails to decompress becouse of to few disk space. This is the worst feature that has ever been invented.

Thanks for your attention, I am a bit angry and wanted to share my view. By the way, does anybody konw why the GNOME people are ignoring ignoring this now since 7 years? This is definetly not a feature, this is just stupid.

Nick B. (futurepilot) wrote :

I wrote about this 4 years ago. http://linuxtechie.wordpress.com/2010/01/05/file-roller-is-terribly-inefficient/ You hit the exact same points I did. I no longer use Gnome anymore but it's sad to see this stupidity still hasn't been fixed.

Changed in file-roller:
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.