> So, UUID file identifiers look horrible, etc. I agree. But why are we
> then arguing for using them in gvfs? The same arguments apply there.
Because we want to solve the issue of opening a link to an item on a
removable device, and be properly prompted to insert the device.
Whatever this require
I believe I understand all of your points then. I'm mostly just
interested in providing something "useful" to application developers so
they can develop applications that are more "useful" to users.
Persistent bookmarks to removable devices. I think a lot of people would
like to solve this.
The a
Jerome Haltom wrote:
>> So, UUID file identifiers look horrible, etc. I agree. But why are we
>> then arguing for using them in gvfs? The same arguments apply there.
>>
>
> Because we want to solve the issue of opening a link to an item on a
> removable device, and be properly prompted to inse
On Fri, 2007-05-04 at 11:48 -0400, David Zeuthen wrote:
> On Fri, 2007-05-04 at 09:00 -0500, Jerry Haltom wrote:
> > Why doesn't HAL use UUIDs?
>
> Doesn't exactly make sense. Maybe you mean: "Why does my mount points
> not use UUID?". Understand that HAL [1] is only a source of information
> + m
On Fri, 2007-05-04 at 09:00 -0500, Jerry Haltom wrote:
> Why doesn't HAL use UUIDs?
Doesn't exactly make sense. Maybe you mean: "Why does my mount points
not use UUID?". Understand that HAL [1] is only a source of information
+ mechanism to allow g-v-m, KDE, gnome-mount, whatever to mount file
sy
On Fri, 2007-05-04 at 09:00 -0500, Jerry Haltom wrote:
>
> Why doesn't HAL use UUIDs? I'd say probably because up until now there
> was no abstraction to turn those UUIDs into usefully understandable
> paths for the user. If you plug in a USB disk and open Nautilus, you see
> the /media/usbdisk-1
On Thu, 2007-05-03 at 10:18 -0500, Jerry Haltom wrote:
> > The selection of whether to do local or remote i/o is done when
> > instantiating the GFile. We instantiate a GLocalFile or a GDaemonFile
> > depending on the uri and the default GVfs instance loaded. However, the
> > mapping from URI to wh
On Thu, 2007-05-03 at 15:18 -0400, David Zeuthen wrote:
> On Thu, 2007-05-03 at 10:14 +0200, Alexander Larsson wrote:
> > The way a normal application uses gvfs is by the gio apis. Essentially
> > you hand over a uri, and this uri is parsed by custom uri-type specific
> > code into a mount specific
On Thu, 2007-05-03 at 15:45 -0400, David Zeuthen wrote:
> On Thu, 2007-05-03 at 16:59 +0200, Alexander Larsson wrote:
> > The selection of whether to do local or remote i/o is done when
> > instantiating the GFile. We instantiate a GLocalFile or a GDaemonFile
> > depending on the uri and the defaul
On Thu, 2007-05-03 at 09:16 -0500, Jerry Haltom wrote:
> I think HAL should be able to return to us UUIDs which would be valid
> between machines.
Correct (the UID is composed from a number of sources including
filesystem UUID/filesystem label and, if the media is not removable,
also make/model/s
On Thu, 2007-05-03 at 12:43 -0400, Ray Strode wrote:
> Rather than propagating an I/O errors to apps using the stick at the
> time of removal, it could tell the user to reinsert the stick and
> continue where it left off.
Surely brings back memories from the Amiga ("You MUST replace the disk
in dr
I'm usually a lurker here, just chiming in on this:
On Qui, 2007-05-03 at 16:48 +0200, Alexander Larsson wrote:
> 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 moun
On Thu, 2007-05-03 at 16:59 +0200, Alexander Larsson wrote:
> The selection of whether to do local or remote i/o is done when
> instantiating the GFile. We instantiate a GLocalFile or a GDaemonFile
> depending on the uri and the default GVfs instance loaded. However, the
> mapping from URI to what
On Thu, 2007-05-03 at 10:14 +0200, Alexander Larsson wrote:
> The way a normal application uses gvfs is by the gio apis. Essentially
> you hand over a uri, and this uri is parsed by custom uri-type specific
> code into a mount specification (info about a gvfs mountpoint) and a
> path into it. Each
> The selection of whether to do local or remote i/o is done when
> instantiating the GFile. We instantiate a GLocalFile or a GDaemonFile
> depending on the uri and the default GVfs instance loaded. However, the
> mapping from URI to what should be done with the file must be done by
> purely in-pro
> Will it work. I guess, yes. However, it will be slower for gvfs apps,
> and I still think the aliasing is gonna be confusing. I.E there will be
> two visible locations that map to the same place. Code will look at a
> particular location name and don't expect things like a delete in this
> place
On Wed, 2007-05-02 at 14:55 +0200, Alexander Larsson wrote:
> On Tue, 2007-05-01 at 22:34 -0500, Jerry Haltom wrote:
> > I've been reading back in the discussion this February, about GVFS and
> > Alex's design and such. Read the postings about legacy VFS integration
> > and creating a Fuse mount po
On Wed, 2007-05-02 at 00:19 -0400, David Zeuthen wrote:
>
> This uuid could be private to GVFS and there would be a lookaside
> table
I think HAL should be able to return to us UUIDs which would be valid
between machines. Which is interesting, as it means uris such as these
could be saved in sho
Hi,
> allowing you to put up dialogs such as
>
> +--+
> | The application Frobnicator is trying to access a file on a |
> | device that is not available right now. To continue please |
> | attach the device
On Thu, 2007-05-03 at 09:38 -0500, Jerry Haltom wrote:
> > Will it work. I guess, yes. However, it will be slower for gvfs apps,
> > and I still think the aliasing is gonna be confusing. I.E there will be
> > two visible locations that map to the same place. Code will look at a
> > particular locat
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
On Thu, 2007-05-03 at 00:50 -0400, David Zeuthen wrote:
> Or maybe I'm missing something? Feel free to tell me to read docs and/or
> the code if my question is stupid and the answer already lies there.
> Thanks!
Its true that there is a form of mapping going on with the fuse layer.
Here is how it
On Wed, 2007-05-02 at 14:58 +0200, Alexander Larsson wrote:
> On Wed, 2007-05-02 at 00:19 -0400, David Zeuthen wrote:
>
> > This should be a piece of cake to do (assuming HAL) and if people think
> > it's a good idea (I'm not entirely convinced it is) I'd be happy to take
> > a stab at it when GVF
Hi Alexander
On Wed, 2007-05-02 at 14:58 +0200, Alexander Larsson wrote:
> On Wed, 2007-05-02 at 00:19 -0400, David Zeuthen wrote:
>
> > This should be a piece of cake to do (assuming HAL) and if people think
> > it's a good idea (I'm not entirely convinced it is) I'd be happy to take
> > a stab
On Wed, 2007-05-02 at 00:19 -0400, David Zeuthen wrote:
> This should be a piece of cake to do (assuming HAL) and if people think
> it's a good idea (I'm not entirely convinced it is) I'd be happy to take
> a stab at it when GVFS is ready for this. Alex?
I'm not really convinced it is a good idea
On Tue, 2007-05-01 at 22:34 -0500, Jerry Haltom wrote:
> I've been reading back in the discussion this February, about GVFS and
> Alex's design and such. Read the postings about legacy VFS integration
> and creating a Fuse mount point into GVFS at ~/.mount or similar. I find
> that really interesti
On Tue, 2007-05-01 at 22:34 -0500, Jerry Haltom wrote:
> 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`
This uuid could be private to GVFS and ther
27 matches
Mail list logo
