file-roller puts temporary files in the home dir instead of /tmp

Un-marking this as a duplicate of bug 146206. This bug is about file-roller incorrectly using temp files and not cleaning up behind itself. Bug 146206 is about file-roller copying files to a local directory before being extracted.

@nataliya:

Really? A fix has been committed? There's no text explaining this fact. I'd change the status back to Triaged, but I can't do so. Confirmed is the best I can do.

If this bug really has been fixed, please post an explanation so the status change doesn't appear to be a random drive-by change.

This bug is *not* fixed in up-to-date lucid lynx. Files are now written to ~/.cache/.fr-* but this is still not $TEMP.

I would like to reduce the amount of writes to my ssd, while I don't mind writes to /tmp (which is mounted as tmpfs). Yes, I could also mount ~/.cache as tmpfs but doing so would be tedious to setup for every user. (A similar use-case to mine are nfs-mounted homes where $TEMP is likely to be local, while $HOMEDIR is not.)

I second that all temporary files should go into $TEMP, not into $HOMEDIR/.cache

As for now, File Roller 3.2.1 puts its temp files not in folders like '~/.fr-a1b2c3', but in '~/.cache/.fr-a1b2c3', so I've reported that as bug #883628.

Confirmed in 15.04

Very annoying... file-roller 3.20.2-1 on Arch Linux.

I tracked down this bug. The source of the problem is in src/file-utils.c. It looks like File Roller calls _g_path_get_temp_work_dir, which searches the user's cache dir, user's home dir, and tmp, for a place to put the temporary folder. It searches in that order. The criteria for the search is available free space. The location with the most free space will be used. If two locations have the same amount of free space, the one searched first will be used.

The bug is that, at least on my system, /tmp and ~/.cache both have the same amount of free space. So ~/.cache gets used, since it's searched first.

This searching algorithm is reasonable, as opposed to just always using /tmp. What if File Roller is run on a system where /tmp is limited, and now the user can't extract an archive because /tmp keeps blowing up. So it makes sense to use whatever has the most available disk space.

I suggest fixing this by changing the search order. The search order is defined by:

static const char *try_folder[] = { "cache", "~", "tmp", NULL };

Let's change that to:

static const char *try_folder[] = { "tmp", "cache", "~", NULL };

It's a simple change, and for systems like mine, where /tmp is part of the root filesystem, File Roller will use tmp since it should have the same free space as cache.

A better solution may be a compile time option to force a particular folder, or a run-time preference. In both cases it will be up to the distro to configure the appropriate compile option or default preference, according to how their distro installs.

If someone lets me know: where to pull the latest File Roller source code, and how to submit a patch, I can at least submit a patch tweaking try_folder.

The code source is on https://git.gnome.org/browse/file-roller and you can read https://wiki.gnome.org/Newcomers/SubmittingPatches to have details on how to submit a patch to the code

I Deleted the ~/.cache/.fr-* files and saved 117GB on a 480GB SSD drive. My system had gone down with less than 500mb in free space after the last view zip file crash and my system would no longer let me log in to my main account (Constant re login attempts). I had to use the log in for fixing the system at the startup prompt and the system came up to Debian not Ubuntu 16.10. I Timeshifted back 2 days to get back to Ubuntu.
May need to look for a different file archive program, this is a big drive eater after a crash.

I've switched to Xarchiver.

The problem is not entirely that files are not created in /tmp, but rather that nothing cleans them up in the event of a crashed or killed process. I also see these files in the current directory as well as tmp and .cache

As these directories are prefixed with a dot, less technical users will probably not see them as the default in the file manager is to hide them. I found over 2.5GB of these files on my system, which means they are also taking up backup space and resources, too.

i'm on Ubuntu 14 lts (16 didnt even boot up on this device, so i didnt bother to update, its an LTS after all)

not only this bug is still present but i found another one:
if you open an image protected by password in an zip file, then close the file roller, the image disapear, i guess that is the expected, but there is another issue.
even if you close the image, if you put the computer to hibernate, then return from it (the hibernate status)
the image will open again...

i'm not sure what is happening here, but here is what i guess:
i was seeing some password protected files, something crash on the background so i had to kill some processes including firefox, i'm not sure if i killed the file roller too and the pp files (password protected) or they close automatically and the system was trying to recover from crash, i constantly closed an openend pp files sometimes, and set the computer to hibernate, when i wake up the computer, the files where openend many times, as if i never had closed then.