GNOME Bugzilla – Bug 646391
gvfs should use g_get_user_runtime_dir
Last modified: 2013-01-30 10:21:28 UTC
Would be good to use the XDG runtime directory provided by g_get_user_runtime_dir() instead of /tmp for sockets etc.
Created attachment 184901 [details] [review] Use user runtime dir instead of tmp for burning
Created attachment 185010 [details] [review] Use user runtime dir for gvfs mounts
*** Bug 646512 has been marked as a duplicate of this bug. ***
*** Bug 646493 has been marked as a duplicate of this bug. ***
Looks good to me, we should land this post branching though.
(In reply to comment #5) > Looks good to me, we should land this post branching though. Alex: Has this happened? If not, can this get in?
Tomas, can you take care of this ?
(In reply to comment #1) > Use user runtime dir instead of tmp for burning Is "burning" the huge image file? Not sure about /tmp or /run for burning DVDs. /run is required to be a tmpfs, and can not carry more than half of the system's RAM at maximum. /tmp should ideally a tmpfs by default too (I have that on all of my boxes). The only safe bet for storing gigabytes of temporary files is usually /var/tmp, which needs to reside on disk. We might need to consider /var/tmp to use as storage for large temporary files.
(In reply to comment #2) > Use user runtime dir for gvfs mounts That looks great. Thanks!
> The only safe bet for storing gigabytes of temporary files is usually /var/tmp, > which needs to reside on disk. We might need to consider /var/tmp to use as > storage for large temporary files. Ok. Should probably still be per user though.
Both patches look good to me and things seem to be working fine. A fallback path is assured when $XDG_RUNTIME_DIR is not set, e.g. for systems having no /run. (In reply to comment #8) > (In reply to comment #1) > > Use user runtime dir instead of tmp for burning > > Is "burning" the huge image file? Not sure about /tmp or /run for burning DVDs. > /run is required to be a tmpfs, and can not carry more than half of the > system's > RAM at maximum. /tmp should ideally a tmpfs by default too (I have that on all > of my boxes). Looking at the burn backend sources, I see traces of temp files and dir creation however there's no way how to actually copy/move data there. No write operations are implemented and the Push operation returns error when trying to move data into the backend. So basically the burn backend is pure virtual. Correct me if I'm wrong, I expect the burning application to read burn:/// structure and handling temporary image file itself (which is not really needed usually). > The only safe bet for storing gigabytes of temporary files is usually /var/tmp, > which needs to reside on disk. We might need to consider /var/tmp to use as > storage for large temporary files. Lots of people I know links /var/tmp to /tmp for not having temporary files spread all over the disk. While it's their problem, they might not be aware of that and turning /tmp to tmpfs might come as a surprise. But hey, I guess we don't care about this situation.
I went ahead and committed both patches in master. I'm still convinced the burn backend not storing anything in its temporary folder. If that's not the case feel free to reopen this bugreport. commit 989d0889afe34a0ce072edf9840b6d18314a00b3 Author: William Jon McCann <jmccann@redhat.com> Date: Tue Feb 7 12:15:43 2012 +0100 burn: Use user runtime dir instead of /tmp https://bugzilla.gnome.org/show_bug.cgi?id=646391 Signed-off-by: Tomas Bzatek <tbzatek@redhat.com> commit f81e381b58bf4dc8ea42ceb50311d4ef92677f72 Author: William Jon McCann <jmccann@redhat.com> Date: Tue Feb 7 12:14:48 2012 +0100 Use user runtime dir for gvfs mounts https://bugzilla.gnome.org/show_bug.cgi?id=646391 Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
Reopening because we now show a gvfs entry called 'gvfs' (by design we want to show mounts in $XDG_RUNTIME_DIR) Mount(0): gvfs -> file:///run/user/davidz/gvfs Type: GProxyMount (GProxyVolumeMonitorUDisks2) default_location=file:///run/user/davidz/gvfs themed icons: [drive-removable-media] [drive-removable] [drive] can_unmount=1 can_eject=0 is_shadowed=0 sort_key=gvfs.time_detected_usec.1328727771883490 http://people.freedesktop.org/~david/nautilus-with-gvfs-dir.png So we need to either blacklist this mount or prefix with a dot, e.g. use $XDG_USER_RUNTIME_DIR/.gvfs .. I suggest the latter
Oh mounts go right under $XDG_USER_RUNTIME_DIR by default? Perhaps another option is to move them under a mounts subdirectory?
(In reply to comment #14) > Oh mounts go right under $XDG_USER_RUNTIME_DIR by default? Perhaps another > option is to move them under a mounts subdirectory? It's $XDG_USER_RUNTIME_DIR/media actually, but the point is that we show all mounts in $XDG_USER_RUNTIME_DIR just like we have always shown everything in $HOME
OK, I've changed the udisks2 monitor to only show $XDG_RUNTIME_DIR mounts if they are in $XDG_RUNTIME_DIR/media http://git.gnome.org/browse/gvfs/commit/?id=60968576962f10212caf9e59a41ef0a9f77e6165 which resolves the problem mentioned in comment 13. Closing.
*** Bug 669797 has been marked as a duplicate of this bug. ***
Hi, I have a question about the tempdir. It is used only for file.XXXXXX right? But in the code, it seems never reach the 301 line. 294 file = virtual_node_new (name, VIRTUAL_NODE_FILE); 295 296 if (backing_file != NULL) 297 { 298 file->backing_file = g_strdup (backing_file); 299 file->owned_file = FALSE; 300 } 301 else 302 { 303 template = g_build_filename (backend->tempdir, "file.XXXXXX", NULL); 304 When the local_path is NULL, it will return immediately. 831 if (g_stat (local_path, &stat_buf) == -1) 832 { 839 return TRUE; 840 } Thanks, David (In reply to comment #0) > Would be good to use the XDG runtime directory provided by > g_get_user_runtime_dir() instead of /tmp for sockets etc.