GNOME Bugzilla – Bug 677272
Please add g_get_tmp_dir() like call that returns /var/tmp
Last modified: 2018-05-24 14:15:56 UTC
A number of distributions are currently in the process of switching to tmpfs for /tmp. A side effect of that is that if applications need to store large temporary files, or temporary files that should be kept across reboots they shouldn't be using /tmp for that anymore, and use /var/tmp instead. https://lwn.net/Articles/499410/ http://fedoraproject.org/w/index.php?title=Features/tmp-on-tmpfs Currently glib doesn't appear to have a call like g_get_tmp_dir() that returns the appropriate temporary directory for big/persistant files. I'd thus like to see added one call, possibly called g_get_big_tmp_dir() or so, that returns /var/tmp on Linux/Unix. It should still honour $TMPDIR as first choice if that is set so that the user can redirect all temporary file generation with one variable, but ultimately it should return /var/tmp instead of /tmp, if no explicit env var is set. If this is added the documentation for g_get_tmp_dir() should probably be updated to mention that this directory is only for small files that need no persistancy across reboots and g_get_big_tmp_dir() is for everything else. Also see: http://0pointer.de/blog/projects/tmp.html
How would an application know when its data is "big"? The two mentions of /var/tmp in the Fedora feature are: > My CD burning application writes huge .iso files to /tmp, and this breaks on tmpfs! > The application should be fixed to use /var/tmp. So...the distinction is it's not a download? > My application writes temporary files to /tmp and they are gone after a reboot! > The application should be fixed to use /var/tmp. FHS recommends that /tmp is flushed on reboot, and that's what we do here. Note this one has nothing to do with "big".
(In reply to comment #1) > How would an application know when its data is "big"? Well, if they process unbounded user data, it's big. If they use temporary files for internal stuff it's either obvious that it is big, or it is small. > The two mentions of /var/tmp in the Fedora feature are: > > > My CD burning application writes huge .iso files to /tmp, and this breaks on tmpfs! > > The application should be fixed to use /var/tmp. > > So...the distinction is it's not a download? Proper downloads should go to the XDG download directory. Temporary downloads belong in /var/tmp (posibly the XDG cache dir). > > The application should be fixed to use /var/tmp. FHS recommends that /tmp is flushed on reboot, and that's what we do here. > > Note this one has nothing to do with "big". Well, I think the more important property of data is "big", hence I called the function "big". But sure, if you insist on this, another name of g_get_big_and_persistant_tmp_dir() might be a better choice...
Another question: is there ever a case where it is recommended that a non-system service should ever want to put something into /tmp now that we have XDG_RUNTIME_DIR?
(In reply to comment #3) > Another question: is there ever a case where it is recommended that a > non-system service should ever want to put something into /tmp now that we have > XDG_RUNTIME_DIR? Well, at this point it is too late to remove g_get_tmp_dir() anyway, but I think there are good usecases for /tmp still. Stuff like: let's generate But you are right g_get_user_runtime_dir() takes most of the current uses of /tmp away. Example from the top of my head: hugin generates a build script for image processing, then invokes it. THat build script should be in /tmp, and not much other places. It's control data, not payload, and it's temporary.
Ouch, my last comment got weirdly reordered. Let's try this again: (In reply to comment #3) > Another question: is there ever a case where it is recommended that a > non-system service should ever want to put something into /tmp now that we have > XDG_RUNTIME_DIR? Well, at this point it is too late to remove g_get_tmp_dir() anyway, but I think there are good usecases for /tmp still. Example from the top of my head: hugin generates a build script for image processing, then invokes it. THat build script should be in /tmp, and not much other places. It's control data, not payload, and it's temporary. But you are right g_get_user_runtime_dir() takes most of the current uses of /tmp away.
Here's what I was getting at: can't you just set TMPDIR=/var/tmp and get rid of tmp entirely? (or just symlink it to /var/tmp for broken apps that fail to honour TMPDIR). Then people could just go on with using g_get_tmp_dir()....
It's basically the destinction between payload and control. Payload belongs in /var/tmp, control in /tmp. And I think you need both around. What we are doing now is moving payload out of /tmp, but that doesn't mean control won't be needed at all anymore, or could be entirely subsumed into XGD_RUNTIME_DIR.
*** Bug 672939 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/552.