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

[nf <nf2 scheinwelt at>]

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, which
may behave weired. 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 natural thing.
If a program does not deal with them ... well ...

> 
> > -) 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"
> 
> > --> 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.
> 
> > 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.
> 
> > and keep things as simple as possible! Every new virtual-xyz
> > abstraction or event layer seems to cause even more problems...
> True. That's why I was asking if there's another way to get around this ;-)
> 
> Some more code is aviable:
> http://members.shaw.ca/thubble/procnotify.tar.gz It's not by me, but
> by an ivman-devel subscriptor (or how do you say that?) Looks useable.
> 
> Regards, Nicolas