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. -- files are copied to a local directory before being extracted https://bugs.launchpad.net/bugs/146206 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
