File Roller

file-roller leaves gigantic hidden files on disk when it fails due to lack of disk space

Bug #90328 reported by Jason Spiro
30
This bug affects 4 people
Affects Status Importance Assigned to Milestone
File Roller
Confirmed
Medium
file-roller (Ubuntu)
Triaged
Medium
Ubuntu Desktop Bugs

Bug Description

Binary package hint: file-roller

== 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")

Revision history for this message
Daniel Holbach (dholbach) wrote :

Thanks for your bug report. I forwarded it upstream: http://bugzilla.gnome.org/show_bug.cgi?id=415638

Changed in file-roller:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Bug Watch Updater (bug-watch-updater)
Changed in fileroller:
status: Unknown → Unconfirmed
Revision history for this message
Timmie (timmie) wrote :

I con confirm that and it's a disadvantage of the program. Many users don't even know about hidden files and therefore this should be fixed ASAP.

Thanks.

Sebastien Bacher (seb128)
Changed in file-roller:
status: Confirmed → Triaged
Revision history for this message
Sparhawk (theastrochild) wrote :

Just a question, as I've experience this scenario (disk full upon extraction) and would like to search my drives for "hidden left-behind partial archive extracted files" and remove them to regain the disk space potentially wasted....

Where are these files created, in the target (Extract-To) directory, or in a temporary directory somewhere in ~ ?

Revision history for this message
Jason Spiro (jasonspiro) wrote :

Sparhawk, I don't know. But I know that the kleansweep-helper command-line tool that comes with Kleansweep has been able to find temp files left over from disk-full-upon-compression ever since earlier this year, but the Kleansweep GUI cannot. Use the -e option ("search for temporary files").

But Sparhawk, what do you mean "disk full upon extraction"? When I filed the bug, I only realized there was a "disk full on compression" problem. Is there a "disk full on extraction" problem too? Please tell us; we would like to know.

Revision history for this message
Sparhawk (theastrochild) wrote :

Jason,

Oh, I misread your comment. You were -creating- an archive, not extracting one.
I tried my scenario where I extracted an archive to a volume that was nearly full and became full upon extraction and the files were removed when the operation was cancelled.

Revision history for this message
Tome Boshevski (tome-lugola) wrote :

This happened to me when I tried to extract archive but I didn't have enough space and the temp file filled my disk. I tried looking for it but can't find it. It's like 400-500 MB. Anyone knows where I can find it to delete it ? Thanks

Revision history for this message
Endolith (endolith) wrote :

I tried extracting a very large archive on a partition that had plenty of space, but file-roller is apparently copying the entire thing to a hidden file in my home directory first?? This prevents it from unarchiving. Why would it copy to the home directory in the first place?

Revision history for this message
Jason Spiro (jasonspiro) wrote :

> This happened to me when I tried to extract archive but I didn't have
> enough space and the temp file filled my disk. I tried looking for it but can't find it. It's like
> 400-500 MB. Anyone knows where I can find it to delete it ? Thanks

Tome, please try asking your question at www.ubuntuforums.org ; you may get a better response.

Revision history for this message
oss_test_launchpad (oss-test-launchpad) wrote :

When is this bug going to be fixed? Most users do not fancy looking for hidden files, and it might be quite a problem if all of a sudden your hd is full and you don't know why.

Revision history for this message
Sebastien Bacher (seb128) wrote :

there is one person working upstream on his free time on this software and hundred of bugs opened, you can try asking on bugzilla if he plans to work on the issue but there is no publisched schedule

the issue might be annoying but that's how opensource works and you can't tell a volunteer what he has to do when working on his own software, the code is available though and anybody can look at the issue and contribute to the required change

Revision history for this message
Endolith (endolith) wrote :

"that's how opensource works ... the code is available and anybody can look at the issue and contribute to the required change"

No. Only people who understand the code can. That's a much smaller number than "anybody".

Revision history for this message
Sebastien Bacher (seb128) wrote :

> No. Only people who understand the code can. That's a much smaller number than "anybody".

not really no, anybody can look at the code and try to learn, but anyway that's not really the topic and I was trying to explain why there is no change on this bug, not sure what point you are trying to make there exactly now

Revision history for this message
oss_test_launchpad (oss-test-launchpad) wrote :

1) - Has there been any progress on this issue?
2) - Is there an automatic connection between Launchpad and Bugzilla, or are these discussions here all in vain unless someone once more forwards this?

Revision history for this message
Sebastien Bacher (seb128) wrote :

the bug would have been updated if there was some change, and no the launchpad comments are not sent automatically to bugzilla.gnome.org, you are welcome to contribute on the bugzilla bug though, the ubuntu team doesn't have the ressources to work on all the softwares issues in a distribution specific way

Revision history for this message
oss_test_launchpad (oss-test-launchpad) wrote :

Is any knowledgeable person going to make the developers aware of this?

Revision history for this message
Sebastien Bacher (seb128) wrote :

there is already a bug upstream, http://bugzilla.gnome.org/show_bug.cgi?id=415638, as you can see when reading the launchpad page which lists the upstream task too

Revision history for this message
oss_test_launchpad (oss-test-launchpad) wrote :

Oh, sorry. Didn't notice that.

Bug Watch Updater (bug-watch-updater)
Changed in file-roller:
importance: Unknown → Medium
Bug Watch Updater (bug-watch-updater)
Changed in file-roller:
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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