Re: Re: [pickup] [RFC/PATCH] Nonotify - A simplistic way to determine directory content changes

[nf <nf2 scheinwelt at>]

Continued ... i pressed the "send"-button by mistake.

On Mon, 2004-06-21 at 12:15, Ikke wrote:
> > I think number two (auto-Umounting when the media was removed) is a cool
> > thing. I don't believe in auto-mounting though. Mounting should be done
> > manually by the user by clicking on a drive-icon.
> Maybe. But some people don't want it like this, thats why
> super-/submount were invented.

Although supermount seems to be the only working solution to all those
umount problems at the moment - it works on my mandrake (but not very
reliable) - i don't like it:

The reason:

-) It puts a layer on top of the original unix mounting/umounting scheme, which
may behave weird. For instance when you use an application, which
monitors directories/files via polling - "tail" for instance. (Read the
supermount faq.)

-) I believe in a three stage device model: 
     a) media not inserted
     b) inserted but not mounted
     c) mounted.

because sometimes users want to insert media, but NOT mount it - for
instance for multisession cd-recording.

> 
> > And now - my opinion on the drive-locking issue (maybe i am repeating
> > myself):
> > 
> > -) Cdroms don't need to get locked, because they are read-only. Locking
> > only makes sense for read/write devices (To prevent file-system
> > corruption).
> True. But a program relying on the cd can crash if it gets removed (if
> badly written).

Dealing with I/O errors when reading a file is the most basic thing.
A program that does not handle them properly ... well ...
And remember: You can only lock CD-Trays - but no other media...

> 
> > -) Most other devices (Floppies, USB-Harddisks) cannot get locked
> > because they just don't have a lock.
> True indeed. We could warn the user tough: "We got an event you
> removed your stick, but it was in use by program XYZ (pid ABC). Please
> make shure you won't loose any data"

More feedback and transparency is cool. Good idea!

> 
> > --> FORGET about locking and NEVER lock anything!! CDROM-door-locking is
> > just a senseless tradition. ;-)
> Depends I think. Locking a cd tray whilst copying the cd isn't that bad.

But it might be too "expensive" in terms of complexity. If the tray stays locked 
because something went wrong: That's worse than anything else...

> 
> > Please try to solve everything at the lowest possible level (in the
> > kernel)
> I dont want to have to patch the kernel. That's right the goal if
> ivman: to be 100% userland.

Don't misunderstand me - i'm just calling for a "back to the roots" approach: Make
things work before adding tons of features. Stay consistent with the OS underneath.
I'm not a kernel expert, but i think a lot of problems of the linux desktop arise from
feature-fanatism and putting all those layers between the user and kernel-"reality" -
trying to fix problems at the wrong place.

Gnome-vfs might be taken as an example for this: Because smbmount didn't work properly,
they pulled smb-connectivity into gnome-vfs - however breaking compatibility with
all non-gnome applications...

regards,
Norbert