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 415638 - file-roller leaves gigantic hidden files on disk when it fails due to lack of disk space
file-roller leaves gigantic hidden files on disk when it fails due to lack of...
Status: RESOLVED OBSOLETE
Product: file-roller
Classification: Applications
Component: general
2.17.x
Other Linux
: Normal normal
: ---
Assigned To: file-roller-maint
file-roller-maint
Depends on:
Blocks:
 
 
Reported: 2007-03-07 09:18 UTC by Daniel Holbach
Modified: 2020-11-11 19:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Holbach 2007-03-07 09:18:05 UTC
Forwarded from: https://launchpad.net/ubuntu/+source/file-roller/+bug/90328

== Steps to reproduce ==

1. Open File Roller
2. Create a new .tar.gz file on an almost-full disk (If you have a USB flash disk that is almost full, that will work fine.)
3. Add so many files to it that it will take up all free space on your disk

== What happens ==

1. You get an error message[1]
2. A huge partially-complete .tar.gz file is left on your disk (in my case, I had a few 100MB+ files lying around in various places on my hard drive, as it is often nearly-full yet I often take new backups of my USB drive.)
3. **Big problem**: this .tar.gz file is a hidden dotfile

== What should have happened ==

File Roller should never leave dotfiles on disk after you close it, no matter what errors it encountered.

== Proposed solution ==

File Roller should never name its temporary files starting with a period. Instead, it should name them something like temporary_archive_6313. Yes, it looks somewhat ugly when these files are visible to users, and yes, there are other possible solutions. But all other solutions are either slower or can leave dotfiles around in pathological cases. This is the only way to prevent File Roller from leaving orphaned dotfiles around.

== Notes ==

I am using file-roller 2.16.1 which came with Edgy.

[1] Here is the error text I got:
tar: /home/j/.fr.6313.0.jason_backup.tar: Cannot write: No space left on device
tar: Error is not recoverable: exiting now
gzip: /home/j/.fr.6313.0.jason_backup.tar.gz: Cannot write: No space left on device
mv: cannot stat home/j/.fr.6313.0.jason_backup.tar.gz:: Aucun fichier ou repertoire de ce type (note to readers: this means "No such file or directory")
Comment 1 webograph 2007-08-26 18:13:40 UTC
instead of giving better names, fileroller should not use temporary files at all, but extract to the destination (that's the way it works with good ol' tar as well, and i see no valid reason to use tempfiles; moreover, storing files in /tmp adds to the extraction time if the destination is on another file system than /tmp)
Comment 2 FrostyC 2009-10-27 18:04:27 UTC
I've had this problem too, and I agree temp files should go in the /tmp folder. This a huge bug that has deterred me from recommending any Linux Distro with File Roller in it.
Comment 3 André Klapper 2020-11-11 19:11:57 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).