files are copied to a local directory before being extracted

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

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

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

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

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?

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?

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

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

I've sent the bug upstream on http://bugzilla.gnome.org/show_bug.cgi?id=485665

Sebastien, did you manage to reproduce the problem?

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.

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.

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.