File roller creates tmp file on source drive regardless of where the file destination is

[Paul Stimpson]

Package version 3.4.1-0ubuntu1
Architecture: AMD64

I had a large file-set to roll up into a zip file (a Clonezilla image: A folder containing 44 files totalling 47GB on a USB drive). I call this "Drive A". I connected a second drive ("Drive B") to the machine with the intent that I would read the data from Drive A and write the zip file to Drive B in order to avoid head-thrashing on Drive A and maximise throughput.

I right clicked on the folder on Drive A and clicked "Compress..." I used the destination pulldown to indicate I wanted the zip file to be created on Drive B. I started the compression operation.

File-roller created the .zip.tmp file on Drive A in the same folder as the object being compressed instead of on Drive B. This caused the drive head-thrashing I'd been trying to avoid. When the operation was complete, this file was moved to Drive B. This whole process obviously took longer than it would have taken to do the compression just on Drive A. I consider this behaviour sub-optimal.

Please will you modify File-roller's behaviour to create it tmp file on the destination drive?

Thank you.

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

[Sergiu (sergiuhlihor)]

One other side of the bug: the temp file is not created in same location as destination. This makes the extraction of a 2TB file impossible when main OS is installed on a small 256GB SSD, even through the destination is a 8TB RAID array. It's a shame that such design bugs exists when those issues were solved decades ago by many other graphical archivers.