Re: Volume handling proposal

Clearly we should continue to support hardware where this is not
possible.  But I do not think that we should feel limited by the lowest
common denominator; ideally we provide support for the newest and
shiniest features and degrade gracefully on systems where such features
are not available.  This seems to be the attitude taken with respect to
X extensions like Render, randr, and xinerama.  I think that we would do
well to continue this philosophy into lower-level system features like
ejection notification.

Windows, as a reference, has historically not locked media while in use,
choosing instead to, as you mention, return filesystem errors when
processes attempt to access the drive.  Recently, though, this behavior
has been revised to pop up an advisory dialog showing applications with
open files (I think; I don't remember exactly what that looked like and
I don't have a computer with windows on it here)

We could do something similar of course, and also do the same thing for
unmounting from nautilus.  Ideally, such a dialog would allow you to,
for example, accept the consequences and eject the media anyway, which
would require something like supermount as you mention.


On Wed, 2003-09-17 at 14:03, Sean Middleditch wrote:
> On Wed, 2003-09-17 at 16:40, Rob Adams wrote:
> > On Wed, 2003-09-17 at 13:02, Sean Middleditch wrote:
> > > In a similar vein, tho, if we have autodetect, can we show the device,
> > > but not actually mount it until accessed?  Some kind of gnome-vfs flag
> > > or property or something for "this volume is there, but we need to run
> > > the user mount commands before we access it"
> > 
> > Similarly, can we detect when the button on the drive is pressed and
> > either unmount and eject the drive if possible, or if not pop up a
> > dialog listing applications that have open files on the device?  I think
> > that the UNIX way of having to manually unmount is a little
> > counterintuitive.  Mac people I guess are a used to it, but having to do
> > something in the UI when there's already a button for it on the front of
> > the computer seems silly.
> As I understand, a lot of hardware simply *can't* do that kind of
> notification - the OS simply has to keep the media unlocked (unless a
> specific application requests it, i.e., when installing software off the
> CD).  This is why Linux kernel hacks like supermount are so popular -
> the let the drive stay unlocked whenever possible, and simply return
> filesystem errors if apps try to access an open file/directory after
> media has been removed.
> Higher quality and/or newer removable media devices *should* have the
> right kind of notification features.  Whether or not they are
> standardized, or supported by Linux/BSD/Solaris/whatever, is another
> question.  Even if we were to put a dependency on kernel support for
> this, there's still a quite likely possibility of older/crappy hardware
> being used.
> (Hopefully I remembered all that right.  I had a talk with Miguel about
> it some time ago, and that was more or less the gist of it. ;-)
> > 
> > -Rob
> > 
> > _______________________________________________
> > desktop-devel-list mailing list
> > desktop-devel-list gnome org
> >

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]