In <200006200404.WAA13628@aztec.santafe.edu> Richard Stallman (rms@gnu.org) wrote:
> In discussing this problem, several people had possible solutions which were
> all shot down with a similar counterargument: the kernel can't assume that
> the user who is using the floppy drive is at the console.
> It is not 100% guaranteed that the user is at the console.
> But there are millions of machines where this is always true,
> and on all machines this is usually true.
> Thus, the failure that happens when the user is not in fact at the
> console will only happen rarely. If it is not a disaster, it may be
> worth ignoring.
> And if it is possible to enable the feature through a configuration
> switch, users could enable it on their personal desktop machines.
> They could still log in remotely, but they would not use the floppy
> drive when doing so.
> But I have trouble imagining what sort of feature would be based on
> this assumption. How can one take advantage of the assumption that
> the processes that access the floppy are run from the console? Why do
> you think we have to choose between allowing remote logins and
> automatic unmounting of floppies?
When you have system with background processes (something like MS's FindFast)
user can end up with floppy in use ejected. Then system must ask user to put
floppy back (you can corrupt floppy in Windows quite easily by just ignoring
requests to "put floppy 39BC-1102 in drive A:"). The questions is "who to ask?"
Of course there are also other question "How to ask?" (system can be in some
non-trivial mode even on Desktop: console, X, svgalib, etc). It's BIG project
to make floppies work "like in Windows" (and even in Windows floppies do not
work very good): you need changes in VFS, you need "notification daemon", etc.
So far noone even tried to do this - insted kludges like supermount are
proposed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:19 EST