Re: volume:// uri support

[Mathias Hasselmann]

Am Donnerstag, den 13.12.2007, 02:07 -0500 schrieb David Zeuthen:
 On Thu, 2007-12-13 at 08:01 +0100, Mathias Hasselmann wrote:
  Am Donnerstag, den 13.12.2007, 01:17 -0500 schrieb David Zeuthen:
   There's a screenshot here showing integration into Nautilus
   
   http://people.freedesktop.org/~david/gvfs-hal-2-persistent-volume-uris.png
  
  Woah! Wtf! That URL in the screenshot makes me wish we'd have MS-DOS
  style drive letters! That wish scares me. There must be a better
  solution than this geek style techie stuff.
 
 Why do think the URI would ever be displayed in the UI?

The screenshot?

 (In fact, if you want to avoid implementations details like URI's
 leaking into the UI one way of solving that problem is to make them
 really ugly.)

Might be true.

Ciao,
Mathias
-- 
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: volume:// uri support

[Alexander Larsson]

On Thu, 2007-12-13 at 01:17 -0500, David Zeuthen wrote: 
 Hey Alex,
 
 I've attached some preliminary patches to introduce a new volume:// name
 space. The thinking is that g_file_get_uri() will return a persistent
 URI if a local file is on user-visible media.
 
 (Emphasis on user-visible. As in the media is visible in the UI, e.g.
 computer://, Nautilus's sidebar and the file chooser). Notably files on
 your rootfs (which we hide in the UI) will still use file:// URI's.)
 
 For example this snippet
 
  GFile *f;
  f = g_vfs_get_file_for_path (/media/disk/path/to/file.txt);
  uri = g_file_get_uri (f);
  printf (uri is %s, uri);
 
  f = g_vfs_get_file_uri 
 (volume://name=davidz%20data;uuid=1234/path/to/file.txt);
  uri = g_file_get_path (f);
  printf (path is %s, uri);
 
 will print
 
  volume://name=davidz%20data;uuid=1234/path/to/file.txt
  /media/disk/path/to/file.txt

Its sort of neat, but just automatically doing this for all file uris
will cause a lot of grief, with apps not being able to load local files
etc. If we really do something like this it really has to be optional
somehow to the apps.

Also, I don't think this should be in libgio itself. Its really
something that would be part of the unix desktop and not something that
makes sense on other platforms. So, this should go into gvfs.

 Implementation-wise there's little to no overhead except that
 
  - g_vfs_get_file_from_uri() may block the very first time it's
called with a volume:// URI since it needs to construct a
GVolumeMonitor object
 
  - ditto for g_file_get_uri()
 
 I don't think these are real problems; we already block for GDaemonFile
 all the time IIRC. Other notes:

On the contrary, this is a huge problem. GFile was very deliberately
designed to be a low-overhead object. Constructing, walking and checking
aspects of GFiles should *never* do I/O itself, only actual I/O
operations should. It is for all means and purposes a refcounted
path/uri string.

Furthermore, you actually construct a GVolumeMonitor in each process.
This will mean all processes start monitoring /etc/mtab (possibly even
polling it if monitoring is not availible). Not only is this heavy, but
there is no guarantee that it will work, as it requires much more of the
app using gio than a mere sync I/O operation, such as a running
mainloop, which may not be true.

Take your g_local_file_get_uri_scheme() change for instance, for each
call it does a stat-walk of its parents to find the mount,
reads /etc/mtab and tries to look for the mountpath. Then you made
g_local_file_has_uri_scheme() call this (adding an extra memory
allocation on this fast path even though this call was added in addition
to get_uri_scheme() just to avoid that). Now, this function is called
all over nautilus to check if things are in the trash, on the desktop or
whatever, and they are expected to be fast non-io operations (in
nautilus *all* i/o operations should be explicitly async). This is gonna
murder performance...

GDaemonFile never fully resolves its mountpoints until an actual i/o
operation is run, so it doesn't run in to this. Or, actually, this is
not strictly true, as I had to add a single get_mount_info_sync() call
to g_daemon_file_get_path to support the fuse stuff. But this is only
done once per gvfs mount, on the i/o first operation (or get_path) and
it never happens for local files. So while non-ideal its not as much of
a problem it could be. 

 - We probably want g_volume_monitor_get() to keep around a ref to
the singleton when it's called and release that ref, say, 5 seconds
later via a timeout. This is to avoid constructing and tearing down 
volume monitors all the time. Thoughts?

There is no guarantee that a timeout will be called at all. For sync
calls there might not even be a mainloop. (Think of for instance a
commandline app like gvfs-ls.) You just can not use the volume monitor
to implement sync I/O calls, it is designed for implementing a UI.

Now, this doesn't mean the entire idea has to be given up. We just need
to realize the fact that creating a volume: uri from a file: uri is an
I/O operation, and we cannot hide it in the non-I/O parts of GFile. Once
you've made this observation everything get much easier.

No changes are necessary for the local file implementation, we just have
to add a single i/o operation to create a persistant reference GFile
object (g_file_make_persistant_reference()?), and implement that. Your
volume: implementation is really not platform native native, and as such
should live in gvfs, not libgio. This means that it has to be
implemented by the gvfs loadable module, like the hal volume monitor.

When handling such a volume: uri there is no need to do any I/O for
construction, get_uri_scheme, get_uri, get_child, etc. All you need to
do is textual path work, and then only at the time an actual I/O
operation happens you resolve the uuid and either call the local file
implementation (via g_vfs_get_local() or return a 

Re: volume:// uri support

[Brian J. Tarricone]

On Thu, 13 Dec 2007 12:13:33 +0100 Alexander Larsson wrote:

 On Thu, 2007-12-13 at 01:17 -0500, David Zeuthen wrote: 
 
   volume://name=davidz%20data;uuid=1234/path/to/file.txt
   /media/disk/path/to/file.txt
 
 Also, I don't think this should be in libgio itself. Its really
 something that would be part of the unix desktop and not something
 that makes sense on other platforms. So, this should go into gvfs.

Not really weighing in on whether or not it should be in libgio, but I
do think this is something that could make sense on other platforms.

On win32 for example, say you have a computer with one hard drive
partition (c:) and an optical drive (d:).  You plug in a USB flash
drive, and it gets mounted as e:.  Then you remove that USB flash drive
and plug in a different USB flash drive.  It also gets mounted as e:.

Then you plug in the original USB flash drive (without removing drive
#2), and it gets mounted as f: this time.  Any normal Windows path
'remembered' by an application for this 2nd drive is now incorrect.

On Mac, you have a similar situation, though it's possible to run into
it less often.  MacOS X creates a folder under /Volumes/ based on the
drive's volume label.  You only have a problem if you have multiple
drives with the same volume label.  People who have more than one USB
flash drive from the same manufacturer who don't change the drive label
will be in trouble here, as the first drive plugged in will
be /Volumes/(LABEL), and the second will be /Volumes/(LABEL)-1 and so
on.

-brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: volume:// uri support

[Alexander Larsson]

On Thu, 2007-12-13 at 03:46 -0800, Brian J. Tarricone wrote:
 On Thu, 13 Dec 2007 12:13:33 +0100 Alexander Larsson wrote:
  
  Also, I don't think this should be in libgio itself. Its really
  something that would be part of the unix desktop and not something
  that makes sense on other platforms. So, this should go into gvfs.
 
 Not really weighing in on whether or not it should be in libgio, but I
 do think this is something that could make sense on other platforms.
 
 On win32 for example, say you have a computer with one hard drive
 partition (c:) and an optical drive (d:).  You plug in a USB flash
 drive, and it gets mounted as e:.  Then you remove that USB flash drive
 and plug in a different USB flash drive.  It also gets mounted as e:.
 
 Then you plug in the original USB flash drive (without removing drive
 #2), and it gets mounted as f: this time.  Any normal Windows path
 'remembered' by an application for this 2nd drive is now incorrect.
 
 On Mac, you have a similar situation, though it's possible to run into
 it less often.  MacOS X creates a folder under /Volumes/ based on the
 drive's volume label.  You only have a problem if you have multiple
 drives with the same volume label.  People who have more than one USB
 flash drive from the same manufacturer who don't change the drive label
 will be in trouble here, as the first drive plugged in will
 be /Volumes/(LABEL), and the second will be /Volumes/(LABEL)-1 and so
 on.

What I mean is that the implementation described (using volume: uris
that list the UUID and looking it up in mtab) is not really what you
might want on all platforms. The idea of persistent file identifiers can
be availible in the gio API, but not the modern-unix-desktop-specific
implementation.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: volume:// uri support

[David Zeuthen]

On Thu, 2007-12-13 at 12:13 +0100, Alexander Larsson wrote:
   1. Introduce g_file_get_stable_uri() and always make g_file_get_uri()
  return file:// URI's for local files
 
 Given the above, this is the only workable solution.

Thanks for the detailed reply; I pretty much agree with all your points;
I'll change these things and will include this in the hal patch. Btw,
the volume:// URI scheme should probably be proposed on freedesktop.org
too so the other VFS systems on the free desktop can benefit (with hal
or udev or similar OS services available it's a walk in the park to
implement).

  David


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

volume:// uri support

[David Zeuthen]

Hey Alex,

I've attached some preliminary patches to introduce a new volume:// name
space. The thinking is that g_file_get_uri() will return a persistent
URI if a local file is on user-visible media.

(Emphasis on user-visible. As in the media is visible in the UI, e.g.
computer://, Nautilus's sidebar and the file chooser). Notably files on
your rootfs (which we hide in the UI) will still use file:// URI's.)

For example this snippet

 GFile *f;
 f = g_vfs_get_file_for_path (/media/disk/path/to/file.txt);
 uri = g_file_get_uri (f);
 printf (uri is %s, uri);

 f = g_vfs_get_file_uri 
(volume://name=davidz%20data;uuid=1234/path/to/file.txt);
 uri = g_file_get_path (f);
 printf (path is %s, uri);

will print

 volume://name=davidz%20data;uuid=1234/path/to/file.txt
 /media/disk/path/to/file.txt

There's a screenshot here showing integration into Nautilus

http://people.freedesktop.org/~david/gvfs-hal-2-persistent-volume-uris.png

The patch to Nautilus also includes a small patch to show the URI in the
Location file under preferences; this is just for testing. Also, note
that the GUnixVolumeMonitor doesn't implement this yet; only the hal one
does (finding file system uuid's requires root privileges) - I'll get
around to send the finished hal patch tomorrow...

(there's also a bugfix in the Nautilus patch in src/nautilus-pathbar.c)

Anyway, the thinking is that this can be used in

 - Things like Rhythmbox, Banshee, F-Spot etc. to make sure things Just
   Work(tm) when having collections on removable media / external drives

 - Indexers like Beagle, Tracker etc.

 - Recently used files

Implementation-wise there's little to no overhead except that

 - g_vfs_get_file_from_uri() may block the very first time it's
   called with a volume:// URI since it needs to construct a
   GVolumeMonitor object

 - ditto for g_file_get_uri()

I don't think these are real problems; we already block for GDaemonFile
all the time IIRC. Other notes:

 - We probably want g_volume_monitor_get() to keep around a ref to
   the singleton when it's called and release that ref, say, 5 seconds
   later via a timeout. This is to avoid constructing and tearing down 
   volume monitors all the time. Thoughts?

 - Obviously things don't work when e.g. doubleclicking the icon
   representing /media/disk/path/to/file.txt because gedit isn't
   yet using gio (on my system). This is because Nautilus passes
   a volume:// URI. 

About the latter; there's a couple of options

 1. Introduce g_file_get_stable_uri() and always make g_file_get_uri()
return file:// URI's for local files

 2. Like 1. but reversed; introduce g_file_get_file_uri() (better name
wanted). Then we'd patch the few applications passing URI's to
other applications to use this on.

 3. Just screw it and port applications to gio already. Though there's
the compatibility with other desktops to take into account too.

 4. Like 3. and backport volume:// support to gnome-vfs

Personally I'd just go for option 4. - there's nothing like a little
breakage to help nudge people into fixing their apps to use newer API.
Thoughts?

  David

Index: gunixmount.c
===
--- gunixmount.c	(revision 6105)
+++ gunixmount.c	(working copy)
@@ -167,6 +167,20 @@
   return g_object_ref (unix_mount-icon);
 }
 
+static const char *
+g_unix_mount_get_uuid (GMount *mount)
+{
+  return NULL;
+}
+
+static const char *
+__g_unix_mount_get_mount_path (GMount *mount)
+{
+  GUnixMount *unix_mount = G_UNIX_MOUNT (mount);
+
+  return unix_mount-mount_path;
+}
+
 static char *
 g_unix_mount_get_name (GMount *mount)
 {
@@ -340,6 +354,8 @@
   iface-get_root = g_unix_mount_get_root;
   iface-get_name = g_unix_mount_get_name;
   iface-get_icon = g_unix_mount_get_icon;
+  iface-get_uuid = g_unix_mount_get_uuid;
+  iface-get_mount_path = __g_unix_mount_get_mount_path;
   iface-get_drive = g_unix_mount_get_drive;
   iface-get_volume = g_unix_mount_get_volume;
   iface-can_unmount = g_unix_mount_can_unmount;
Index: glocalvfs.c
===
--- glocalvfs.c	(revision 6105)
+++ glocalvfs.c	(working copy)
@@ -1,3 +1,5 @@
+/* -*- mode: C; c-file-style: gnu; indent-tabs-mode: nil; -*- */
+
 /* GIO - GLib Input, Output and Streaming Library
  * 
  * Copyright (C) 2006-2007 Red Hat, Inc.
@@ -23,6 +25,8 @@
 #include config.h
 #include glocalvfs.h
 #include glocalfile.h
+#include gvolumemonitor.h
+
 #include gio/gdummyfile.h
 #include sys/types.h
 #ifdef HAVE_PWD_H
@@ -77,29 +81,69 @@
   return _g_local_file_new (path);
 }
 
+#include string.h
+
 static GFile *
 g_local_vfs_get_file_for_uri (GVfs   *vfs,
   const char *uri)
 {
+  char *uuid;
   char *path;
   GFile *file;
+  gsize path_offset;
+  char *local_path;
+  const char *mount_path;
+  GVolumeMonitor *volume_monitor;
+  GMount *mount;
 
-  path = g_filename_from_uri (uri, NULL, NULL);
+  if (g_str_has_prefix 

Re: volume:// uri support

[Mathias Hasselmann]

Am Donnerstag, den 13.12.2007, 01:17 -0500 schrieb David Zeuthen:
 There's a screenshot here showing integration into Nautilus
 
 http://people.freedesktop.org/~david/gvfs-hal-2-persistent-volume-uris.png

Woah! Wtf! That URL in the screenshot makes me wish we'd have MS-DOS
style drive letters! That wish scares me. There must be a better
solution than this geek style techie stuff.

Ciao,
Mathias
-- 
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: volume:// uri support

[David Zeuthen]

On Thu, 2007-12-13 at 08:01 +0100, Mathias Hasselmann wrote:
 Am Donnerstag, den 13.12.2007, 01:17 -0500 schrieb David Zeuthen:
  There's a screenshot here showing integration into Nautilus
  
  http://people.freedesktop.org/~david/gvfs-hal-2-persistent-volume-uris.png
 
 Woah! Wtf! That URL in the screenshot makes me wish we'd have MS-DOS
 style drive letters! That wish scares me. There must be a better
 solution than this geek style techie stuff.

Why do think the URI would ever be displayed in the UI?

(In fact, if you want to avoid implementations details like URI's
leaking into the UI one way of solving that problem is to make them
really ugly.)

  David


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list