GNOME Bugzilla – Bug 633778
GVFS mounting directory should be out of HOME
Last modified: 2012-06-22 14:28:13 UTC
.gvfs directory with mounted file systems in HOME: - breaks normal functionality of "searching files" operations (for example, using mc, or find, some else), because it tries to find on all GVFS-mounted directories - breaks normal backup of home directory (the same as above) - brings possibility of removing important files accidentally (when you need to move or remove user profile) - and so on... I suggest to move .gvfs somewhere from home, for example: /mnt/.gvfs (permissions 777) /mnt/.gvfs/user1 (700) /mnt/.gvfs/user2 (700) /mnt/.gvfs/user3 (700) or something like that. Stas
This is a copy of my comment at http://brainstorm.ubuntu.com/idea/7673/ Let me react to some of the comments above, given that I nearly destroyed the contents of several auto-mounted shares in my company. "First the example is flawed, why would you remove your $HOME?" -> If you use a remote system, even if only for a day of two, you do some work on it, you log in to websites and stuff, you may at one point leave this system for good. Consider you want to remove any traces of your private stuff, so that no BOFH can log into your email account (or anything else). How would you do that? "OK, and what if it's mounted under /mnt/gvfs/*, and I do a rm -rf /?" -> I agree that this is a dangerous thing to do, but this is equally dangerous on ANY Linux distribution and should be taught to anyone using a Linux system before. Being discussed here is the danger of a special feature, available in only a subset of all installed Linux systems. You would agree that someone knowing how to use KDE should be able to work with GNOME without the risk of doing what we are discussing, wouldn't you? "Situation what you described is real? I think rm -rf default don't remove files from other file system." It did in my case (Ubuntu 11.04). Later I noticed that --one-file-system exists, but only few systems support this, so it's not very well-known (or is it?). At the least, it's not the default setting. "Why the hell are you deleting your home directory?" See above. Some context: I'm not new to Linux in a way that I wouldn't know about symlinks and mount points, and the concept of one global file system containing all mounted drives and shares. I know about the dangers of "rm -rf /". However, I would not even be able to tell apart one distribution from another, and I assume that a range of Linux users can be assigned to this category. In this view, the pure concept of *automatically*, *non-interactively* mounting network shares in a *hidden* folder in your *home* directory is ultimate danger for any network-accessible data, as long as this is not part of all Linux distributions (which will most probably never be the case).
Not commenting on the sanity of rm -rf $HOME, bit we might want to move the gvfs mountpoints to XDG_RUNTIME_DIR anyway, which would solve your problem as a side-effect.
Reading http://lists.freedesktop.org/archives/xdg/2010-November/011681.html the XDG_RUNTIME_DIR sounds like a good idea. We might want to move certain backend-specific data there as well, e.g. the burn backend tmp files. (In reply to http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html) > If the user logs in more than once he should get pointed to the same directory, > and it is mandatory that the directory continues to exist from his first login > to his last logout on the system, and not removed in between. (Note that this doesn't work at the moment either) Gvfs-fuse-daemon connects to running gvfsd daemon via d-bus. Every running desktop session carries its own gvfsd instance. If we're pointed to the same XDG_RUNTIME_DIR directory for every session, we may end up with collisions. Would be great to have separate fuse daemon mounts. > Files in this directory MAY be subjected to periodic clean-up. To ensure that > your files are not removed, they should have their access time timestamp > modified at least once every 6 hours of monotonic time or the 'sticky' bit > should be set on the file. This is pretty dangerous, hopefully the atime workaround only applies to the directory itself, not its contents.
Fuse daemon and the burn backend now use g_get_user_runtime_dir() to get target directory for its files. The old ~/.gvfs path is only used as a fallback when /run is inaccessible. See bug 646391.