On Thu, 2007-05-03 at 09:27 -0500, Jerry Haltom wrote: > Sure, but that hasn't helped the user any. He still has to remember > where he mounted a remote machine, and do the mounting manually. What > I'm talking about would be a GVFS schema for cifs:// that would actually > create a kernel mount. Or nfs://.
But the user can't mount a kernel mount. Only root can do that. In fact, this is one of the primary reasons we're creating a user space vfs. So that any user can create a cifs mount on any platform without being root. > > > What about auto mounting things such as USB devices? Are we going to > > > have an abstraction around those, where you could refer to device by > > > uuid or something? > > > > > > `uuid-of-device://path/to/file` > > > > > > Or are we simply going to consider it `file:///media/usbdisk-1/` and > > > stuff like we do now? I really like the abstraction idea. It would > > > basically be a GVFS mountable that just did whatever pmount work was > > > necessary to get the device mounted, the proxy to the kernel VFS. > > > > I haven't planned anything like this. There is an abstraction similar to > > gnome-volume-monitor for enumerating the devices, but once they are > > mounted we refer to them as in the filesystem. > > Again, hasn't helped the user any. He can't record these paths in recent > files, because the mount point could change between usages or machines. > One day usbdisk could be usbdisk-1, the next it could be usbdisk-2. Sure, paths have problems. But your made up uuid uri has problems too. Like aliasing, or the risk of non-unique uuids and other fragility problems. > > Not sure what you mean. gvfs backends can support mount on demand if > > that is what you want. But fuse mounts are not really different than any > > other kind of mounted filesystem, what special needs do you have? > > The only need I'm talking about is hiding the actual POSIX location of > the mount from the user. If the user is talking about flickerfs, he > should be able to refer to it as flickerfs://, and not have to refer to > it as file:///mnt/myflicker/. In general the user shouldn't have to type uris at all. If a flickerfs is mounted it should be there in the ui, clickable. And anyway, we won't mount the flickerfs system like that. It will be a user-level mount that is accessed through gvfs and addressed using URIs. > > I'm not sure what you mean, generally file: uris map to POSIX paths, and > > no other do. > > But wouldn't you want to be able to provide a map to POSIX paths for > *all* GVFS urls? For sftp://, smb:// and all the others. There has been > talk on this thread about creating a ~/.local/mounts/ Fuse directory > which would allow non-GVFS enabled programs to use GVFS files. How > should a GVFS enabled program go about translating a GFile to this path? > Hence the `posix-path` property. For `file:///foo/bar` it would return > `/foo/bar`. For `smb://host/foo/bar` it might return > `~/.local/mounts/smb;whatever;whatever/foo/bar`. Hence you can simply > ask a GFile instance for it's POSIX path, and get one. The g_file_get_path() is meant to return the fuse path in case of a non-native GFile when there is fuse support. This works exactly like you say above. It is possible to make it point to other locations than ~/.mounts/ if we make uri schemes that just alias part of the unix tree, but as i said in my reply to davidz, I think that is very risky to do. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc [EMAIL PROTECTED] [EMAIL PROTECTED] He's a benighted coffee-fuelled librarian haunted by memories of 'Nam. She's a pregnant French-Canadian archaeologist who believes she is the reincarnation of an ancient Egyptian queen. They fight crime! _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list