Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 17:39 -0500, Sean Middleditch wrote: Just a reminder that : is the separator used in the PATH environment variable, and is thus a poor choice for use in directories. In all honesty, if the intended use case for reading the directory info is for FUSE and GVFS, I think it would be a lot cleaner to just put some kind of user-friendly name in ~/.mounts/, and then create a ~/.mountrc config file that maps the names to mount parameters which the FUSE fs and GVFS can use to recreate the mount points. Basically, it'd just be a per-user fstab replacement. I want to make sure this takes NFS mounted home directories into consideration. I think perhaps ~ is a very poor choice of location for this. Add in a few CLI utils to call mount with the right parameters for mounts in ~/.mountrc, and you'll have a pretty solid system for both modern GUI, legacy GUI, and CLI users. You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Sure, those are requred. But say we have two optional things, like user and domain, as in smb:server:share:user:domain. But what do we then do if user is unset, but domain isn't. I guess one could do smb:server:share::domain. Still, it requires very specific handling of each type of share with a specified option order etc. A key=value approach is more generic. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
Just a reminder that : is the separator used in the PATH environment variable, and is thus a poor choice for use in directories. In all honesty, if the intended use case for reading the directory info is for FUSE and GVFS, I think it would be a lot cleaner to just put some kind of user-friendly name in ~/.mounts/, and then create a ~/.mountrc config file that maps the names to mount parameters which the FUSE fs and GVFS can use to recreate the mount points. Basically, it'd just be a per-user fstab replacement. Add in a few CLI utils to call mount with the right parameters for mounts in ~/.mountrc, and you'll have a pretty solid system for both modern GUI, legacy GUI, and CLI users. You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Sure, those are requred. But say we have two optional things, like user and domain, as in smb:server:share:user:domain. But what do we then do if user is unset, but domain isn't. I guess one could do smb:server:share::domain. Still, it requires very specific handling of each type of share with a specified option order etc. A key=value approach is more generic. -- Sean Middleditch [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 12:49 -0600, Hans Petter Jansson wrote: On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote: On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: However, the first method you describe: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt sounds perfect. It's rich (we can get back the mount info later), extensible (we don't have to figure out the entire set of potential mount options in advance) and fairly simple (the root nodes are all direct children of ~/.mounts). You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Yeah - the actual syntax is still up in the air, but we need to define it carefully. Do you think ':' is a good separator? I'm not sure you'll always be accessing a share (subdirectory) on the server. I guess we could make the share be / in that case... In the current code browsing a share and browsing a server/workgroup is two different types, smb-share and smb-server. This is required to map correctly on the weird thing that is smb uris. So, this is not really a problem in this particular case. The problem of multiple optional options is still in the generic case though. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a deeply religious Jewish paranormal investigator who must take medication to keep him sane. She's a ditzy tempestuous wrestler descended from a line of powerful witches. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 14:22 -0600, Hans Petter Jansson wrote: On Thu, 2007-02-22 at 13:51 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote: You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Sure, those are requred. But say we have two optional things, like user and domain, as in smb:server:share:user:domain. But what do we then do if user is unset, but domain isn't. I guess one could do smb:server:share::domain. Still, it requires very specific handling of each type of share with a specified option order etc. A key=value approach is more generic. I suppose ~/.vfs/smb:$server:$share/dir/file.txt:option=$value:option=$value You mean ~/.vfs/smb:$server:$share:option=$value:option=$value/dir/file I assume? is a workable compromise. It might even be what Damon was indicating. Now that we're picking on details, I'd say that .vfs or .gvfs would be a better base directory than .mounts too. This would work, and would look better. It still requires specific code for each possible backend to map from path back to the mount info though. (i.e. you need to know that for smb the first two items are server and share.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an obese neurotic vampire hunter with acid for blood. She's an artistic psychic schoolgirl who inherited a spooky stately manor from her late maiden aunt. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 14:51 -0600, Hans Petter Jansson wrote: On Thu, 2007-02-22 at 14:44 +0100, Alexander Larsson wrote: In fact, its likely they implement this by just stat()ing all the files in the recent list. This is a great example of where automounting would royaly screw things up. Given a traditional unix system there wouldn't be anything bad with a solution like that (in fact, it would be very nice to not show deleted files in the recent menu). However, if any stat can lead to indefinite blocking and displaying of random authentication dialogs you suddenly have to do something much more complicated in order to not suck. That's a good point. To make that suck less, you'd probably have to - Immediately deny any access to unmounted shares. - Pop up a dialog asking the user if it should be mounted (if the mount metadata could be converted to a more display-friendly string, such as a URI or even a chosen name, that would be great). - Optionally mount it. So, when the app reads the data for recent files and stats it, or does some other similar operation you'll pop up a dozen dialogs allowing you to mount things like ftp.gnome.org again. You click no several times, and two seconds later they all pop up again. Believe me, things like this happen, all the time. I have to be extremely careful in nautilus for example to never ever access (even get info about) things like history or bookmarks except when the user explicitly browse into them, otherwise we pop up dialog to left and right, when the user don't expect this at all. I much prefer a system where the app can either just ignore the failed stat (if it was an unimportant operation), or in case an open fails display an error that the pathname couldn't be opened, with a pathname that users can understand. Especially when said pathname is also likely to appear in the user interface (in the file selector). The bad part is that the application's access denied and the I think you're trying to mount something dialogs would pop up simultaneously. With gnome-keyring integration, this problem would largely go away, though. In most cases, gvfs could fetch the auth information transparently then go ahead and mount. Its unfortunate that due to todays stateless gnome-vfs that doesn't ever reuse server connections between processes we have to use gnome-keyring as a poor-mans connection-sharing. This is really not a good idea in general, as it means you tend to store all your passwords (like smb or sftp passwords that are often the same as your system password!) in gnome-keyring. Which is *not* recommended as good password hygiene. (i.e. anyone in front of your unlocked desktop, say when you're on lunch, can easily extract all your passwords from gnome-keyring. Handing out passwords is after all what gnome-keyring is designed to do.) Lets not propagate such use further. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a lounge-singing albino jungle king with a passion for fast cars. She's a chain-smoking cigar-chomping doctor who can talk to animals. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 22:26 +0100, Nikolai Weibull wrote: On 2/22/07, Hans Petter Jansson [EMAIL PROTECTED] wrote: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt I just want to point out that there's a freedesktop specification for where things should be stored. Not many seem to respect it, but I, for one, really would appreciate it if people would, as the root of my ~ isn't a junkyard for files and directories. My OCD really needs it to be in order. http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html The basedir spec is for data and config files though. Whereas this is a mountpoint for user files. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a time-tossed albino waffle chef with a winning smile and a way with the ladies. She's a ditzy gold-digging hooker on her way to prison for a murder she didn't commit. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: This won't work. We need to be able to extract all the mount information from the path, so that if the app stores the path across sessions, say, in recent documents, the FUSE layer will know what to do when it's accessed later. I'm just not certain this is true. I mean, we already have this problem with say filenames pointing to unmounted NFS shares, or to removable media. Is this a huge problem? You'll just get an error that the file is not there, go ah, yeah, click on the icon to mount the share and try again. Most URIs also look like total ass. It depends on what you're used to. And ass or not, being able to access a document on a remote share when it's launched with or dragged to a legacy app trumps it. I'm sure users of e.g. MPlayer or Acroread would thank us. There are also plenty of GNOME apps that never worked with non-local files :) In almost all cases where mplayer or acroread were involved things would work perfectly fine, as you're using a desktop to start said files, so the shares were already mounted. If the file was availible to the user to open, click on, dnd, cut'n'paste, etc then the filesystem is mounted, and there will be no problem. The only case where things get problematic is if a filename was stored in a config file (recent files being the typcial example), and the file is on a share that is not normally mounted in your day-to-day workflow. Also, you're saying that if we can't automount on pathname access then its not useful. However, this can lead to all sorts of problems because the mount operation can do things like open authentication dialogs. Such stateless behaviour is causing problems in gnome-vfs and is what we're trying to move from. For instance, the authentication dialogs will never have the right transient-to information and can easily get lost (especially if the app has a modal dialog up). And during the authentication the application will likely be blocked, not even redrawing its UI, which will look very broken. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a benighted arachnophobic vampire hunter living undercover at Ringling Bros. Circus. She's an elegant hip-hop cab driver with an incredible destiny. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: However, the first method you describe: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt sounds perfect. It's rich (we can get back the mount info later), extensible (we don't have to figure out the entire set of potential mount options in advance) and fairly simple (the root nodes are all direct children of ~/.mounts). You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Just a thought, Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 10:33 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: This won't work. We need to be able to extract all the mount information from the path, so that if the app stores the path across sessions, say, in recent documents, the FUSE layer will know what to do when it's accessed later. I'm just not certain this is true. I mean, we already have this problem with say filenames pointing to unmounted NFS shares, or to removable media. Is this a huge problem? You'll just get an error that the file is not there, go ah, yeah, click on the icon to mount the share and try again. As a further example of this I tried OSX. It has a system similar to the first proposal. I.E. When you mount smb://server/share in the finder it appears as the unix mount /Volume/server;share, and connecting to ftp://ftp.gnome.org/ gives you a /Volume/ftp.gnome.org mount. It handled the recent files case by not showing the recently opened file in the recent files menu when it was on a share that is no longer mounted. However, if I remounted it it appeared again. (Although i did have to restart the app, which is sort of crap.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an all-American guitar-strumming gentleman spy who dotes on his loving old ma. She's a mistrustful gypsy traffic cop from a secret island of warrior women. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote: On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: However, the first method you describe: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt sounds perfect. It's rich (we can get back the mount info later), extensible (we don't have to figure out the entire set of potential mount options in advance) and fairly simple (the root nodes are all direct children of ~/.mounts). You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Sure, those are requred. But say we have two optional things, like user and domain, as in smb:server:share:user:domain. But what do we then do if user is unset, but domain isn't. I guess one could do smb:server:share::domain. Still, it requires very specific handling of each type of share with a specified option order etc. A key=value approach is more generic. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a hate-fuelled arachnophobic Green Beret who knows the secret of the alien invasion. She's a cynical out-of-work femme fatale from out of town. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 13:49 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 10:33 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: This won't work. We need to be able to extract all the mount information from the path, so that if the app stores the path across sessions, say, in recent documents, the FUSE layer will know what to do when it's accessed later. I'm just not certain this is true. I mean, we already have this problem with say filenames pointing to unmounted NFS shares, or to removable media. Is this a huge problem? You'll just get an error that the file is not there, go ah, yeah, click on the icon to mount the share and try again. As a further example of this I tried OSX. It has a system similar to the first proposal. I.E. When you mount smb://server/share in the finder it appears as the unix mount /Volume/server;share, and connecting to ftp://ftp.gnome.org/ gives you a /Volume/ftp.gnome.org mount. It handled the recent files case by not showing the recently opened file in the recent files menu when it was on a share that is no longer mounted. However, if I remounted it it appeared again. (Although i did have to restart the app, which is sort of crap.) In fact, its likely they implement this by just stat()ing all the files in the recent list. This is a great example of where automounting would royaly screw things up. Given a traditional unix system there wouldn't be anything bad with a solution like that (in fact, it would be very nice to not show deleted files in the recent menu). However, if any stat can lead to indefinite blocking and displaying of random authentication dialogs you suddenly have to do something much more complicated in order to not suck. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an impetuous ninja cop who hangs with the wrong crowd. She's a vivacious hip-hop advertising executive in the wrong place at the wrong time. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote: On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: However, the first method you describe: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt sounds perfect. It's rich (we can get back the mount info later), extensible (we don't have to figure out the entire set of potential mount options in advance) and fairly simple (the root nodes are all direct children of ~/.mounts). You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Yeah - the actual syntax is still up in the air, but we need to define it carefully. Do you think ':' is a good separator? I'm not sure you'll always be accessing a share (subdirectory) on the server. I guess we could make the share be / in that case... -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 13:51 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote: You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Sure, those are requred. But say we have two optional things, like user and domain, as in smb:server:share:user:domain. But what do we then do if user is unset, but domain isn't. I guess one could do smb:server:share::domain. Still, it requires very specific handling of each type of share with a specified option order etc. A key=value approach is more generic. I suppose ~/.vfs/smb:$server:$share/dir/file.txt:option=$value:option=$value is a workable compromise. It might even be what Damon was indicating. Now that we're picking on details, I'd say that .vfs or .gvfs would be a better base directory than .mounts too. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 14:44 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 13:49 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 10:33 +0100, Alexander Larsson wrote: As a further example of this I tried OSX. It has a system similar to the first proposal. I.E. When you mount smb://server/share in the finder it appears as the unix mount /Volume/server;share, and connecting to ftp://ftp.gnome.org/ gives you a /Volume/ftp.gnome.org mount. It handled the recent files case by not showing the recently opened file in the recent files menu when it was on a share that is no longer mounted. However, if I remounted it it appeared again. (Although i did have to restart the app, which is sort of crap.) In fact, its likely they implement this by just stat()ing all the files in the recent list. This is a great example of where automounting would royaly screw things up. Given a traditional unix system there wouldn't be anything bad with a solution like that (in fact, it would be very nice to not show deleted files in the recent menu). However, if any stat can lead to indefinite blocking and displaying of random authentication dialogs you suddenly have to do something much more complicated in order to not suck. That's a good point. To make that suck less, you'd probably have to - Immediately deny any access to unmounted shares. - Pop up a dialog asking the user if it should be mounted (if the mount metadata could be converted to a more display-friendly string, such as a URI or even a chosen name, that would be great). - Optionally mount it. The bad part is that the application's access denied and the I think you're trying to mount something dialogs would pop up simultaneously. With gnome-keyring integration, this problem would largely go away, though. In most cases, gvfs could fetch the auth information transparently then go ahead and mount. Sure, it'll block the calling application, but if it's using a blocking open(), it always blocks to some extent anyway. We could make the timeout fairly short (say, 10 seconds) when we know we're dealing with a legacy app. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On 2/22/07, Hans Petter Jansson [EMAIL PROTECTED] wrote: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt I just want to point out that there's a freedesktop specification for where things should be stored. Not many seem to respect it, but I, for one, really would appreciate it if people would, as the root of my ~ isn't a junkyard for files and directories. My OCD really needs it to be in order. http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html nikolai ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
