From: Francis GALIEGUE <fra...@mandrakesoft.com>
Subject: Of removable devices
Date: 2000/02/15
Message-ID: <fa.km3qr5v.jjih08@ifi.uio.no>#1/1
X-Deja-AN: 586105404
Original-Date: 15 Feb 2000 13:32:13 +0100
Sender: owner-lin...@vger.rutgers.edu
Original-Message-ID: <m34sbaz...@toy.mandrakesoft.com>
To: linux-...@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
Newsgroups: fa.linux.kernel
X-Loop: majo...@vger.rutgers.edu
Like many other people, I strongly wish that removable device
management were easier under Linux. The supermount patch helped, but
as previously mentioned on this list, it is not clean wrt VFS stuff.
So, the problem remains to be solved.
To the (small) extent of my knowledge, putting this functionality into
the kernel would require that:
- each time a file is accessed on such a device, the VFS should verify
whether the media hasn't changed upon us, and if so, invalidate the
previous superblock, "load" the new one, and check whether the
accessed file exists;
- accessing a file on the device when there's no media should return
-ENOENT and not -EIO, like supermount does;
- prevent dentries preload for such a device
And probably other things I've missed.
What is missing right now in the 2.3.x series in order to create a new
mount flag, say, MS_SLOPPYMOUNT, which would allow for a clean
management of such peripherals?
--
fg
# rm *;o
o: command not found
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: "Khimenko Victor" <kh...@sch57.msk.ru>
Subject: Re: Of removable devices
Date: 2000/02/15
Message-ID: <fa.floel7v.1l2epor@ifi.uio.no>#1/1
X-Deja-AN: 586118714
Original-Date: Tue, 15 Feb 2000 16:25:38 +0300 (MSK)
Sender: owner-lin...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-Id: <ABIFL...@khim.sch57.msk.ru>
References: <fa.km3qr5v.jjih08@ifi.uio.no>
To: fra...@mandrakesoft.com, linux-...@vger.rutgers.edu
Original-References: <m34sbaz...@toy.mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: MCCME
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majo...@vger.rutgers.edu
In <m34sbaz...@toy.mandrakesoft.com> Francis GALIEGUE (fra...@mandrakesoft.com)
wrote:
> Like many other people, I strongly wish that removable device
> management were easier under Linux.
FOR WHO ?
> The supermount patch helped, but as previously mentioned on this list,
> it is not clean wrt VFS stuff.
What's more it'll do more harm then help. Who will use it ? Advanced users ?
Perhaps. But advanced users can create one-linear script, icon on desktop
(with KDE or GNOME even not-so-advanced user can do this :-), etc. No problem.
Dumb user ? Such user will eventually corrunt filesystem on floppy and will
blame Linux for this (simpliest scenario: open file in MC viewer, then delete
it from other MC window). If you want to support only "smart floppies" (ZIP,
MO, etc) you can do this with autofs. WHO will benefit from such patch anyway ?
Do we really need bad press about Linux ?
> So, the problem remains to be solved.
The are exist solution for decent floppies: autofs. It works with decent
floppies (NOT standard 3" & 5" floppies but ZIP, MO, etc) exactly like NT does,
for example. Whatthe problem ?
> To the (small) extent of my knowledge, putting this functionality into
> the kernel would require that:
> - each time a file is accessed on such a device, the VFS should verify
> whether the media hasn't changed upon us, and if so, invalidate the
> previous superblock, "load" the new one, and check whether the
> accessed file exists;
> - accessing a file on the device when there's no media should return
> -ENOENT and not -EIO, like supermount does;
> - prevent dentries preload for such a device
> And probably other things I've missed.
You missed one important thing: what to do with situation where system CAN
NOT be correctly detached (that is floppy can not be easily ejected). One
such situation is outlined above and it's just simples case ...
> What is missing right now in the 2.3.x series in order to create a new
> mount flag, say, MS_SLOPPYMOUNT, which would allow for a clean
> management of such peripherals?
Please describe what you mean by "clean management" and what's not clean
with autofs ?
P.S. I see only one problem with autofs: you can not eject disk when it's
not actually used but merely opened in filemanager. IMO it can be arranged
with changes in drivers, autofs & file managers so said window can be closed
automagically on eject request.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Francis GALIEGUE <fra...@mandrakesoft.com>
Subject: Re: Of removable devices
Date: 2000/02/15
Message-ID: <fa.jn3er5v.1kj6h0d@ifi.uio.no>#1/1
X-Deja-AN: 586150635
Original-Date: 15 Feb 2000 15:34:07 +0100
Sender: owner-lin...@vger.rutgers.edu
Original-Message-ID: <m3vh3q8...@toy.mandrakesoft.com>
References: <fa.floel7v.1l2epor@ifi.uio.no>
To: linux-...@vger.rutgers.edu
Original-References: <m34sbaz...@toy.mandrakesoft.com> <ABIFL...@khim.sch57.msk.ru>
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
Newsgroups: fa.linux.kernel
X-Loop: majo...@vger.rutgers.edu
"Khimenko Victor" <kh...@sch57.msk.ru> writes:
>
> > Like many other people, I strongly wish that removable device
> > management were easier under Linux.
>
> FOR WHO ?
>
<shout>USERS</shout>
> Dumb user ? Such user will eventually corrunt filesystem on floppy and will
> blame Linux for this (simpliest scenario: open file in MC viewer, then delete
> it from other MC window).
Then what? You can forcibly kill processes which access no more
existent files, if these files are on a removable media.
Moreover, this situation is not very different from
opening a file on disk and deleting it in another window. The only
difference is that it'd be killed if the media is gone.
> If you want to support only "smart floppies" (ZIP,
> MO, etc) you can do this with autofs. WHO will benefit from such patch anyway ?
No, you cannot do the following with autofs:
- insert a CDROM, floppy, whatever
- "click on the icon"
- remove the media
- insert another one
- "click refresh"
Yes, that's newbie stuff, and thus, all newbies would benefit from
this. Dumb users, if you wish. And they are by far the most numerous.
> Do we really need bad press about Linux ?
>
If well implemented, it needs no bad press, nor it needs press at all.
>
> The are exist solution for decent floppies: autofs. It works with decent
> floppies (NOT standard 3" & 5" floppies but ZIP, MO, etc) exactly like NT does,
> for example. Whatthe problem ?
>
See above.
>
> You missed one important thing: what to do with situation where system CAN
> NOT be correctly detached (that is floppy can not be easily ejected). One
> such situation is outlined above and it's just simples case ...
>
And it has a simple solution: a forcible kill. After all, it's the
users's fault in this case. You know which processes use a file, if
this file doesn't exist *and* the device is "sloppy-mounted" and not
here -> SIGKILL.
> P.S. I see only one problem with autofs: you can not eject disk when it's
> not actually used but merely opened in filemanager. IMO it can be arranged
> with changes in drivers, autofs & file managers so said window can be closed
> automagically on eject request.
>
It still does not answer my question of what misses in the kernel to
do that... Moreover your solution would require that the media report
media status change. There's AIN for CDROMs, but what for IDE floppies
and the like? Moreover, IDE floppies have no CDROM_LOCKDOOR ioctl
right now (I have a patch for that BTW).
--
fg
# rm *;o
o: command not found
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Alexander Viro <vi...@math.psu.edu>
Subject: Re: Of removable devices
Date: 2000/02/15
Message-ID: <fa.l8dhcfv.5nunb1@ifi.uio.no>#1/1
X-Deja-AN: 586157330
Original-Date: Tue, 15 Feb 2000 10:27:25 -0500 (EST)
Sender: owner-lin...@vger.rutgers.edu
Original-Message-ID: <Pine.GSO.4.10.100021...@weyl.math.psu.edu>
References: <fa.jn3er5v.1kj6h0d@ifi.uio.no>
To: Francis GALIEGUE <fra...@mandrakesoft.com>
X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majo...@vger.rutgers.edu
On 15 Feb 2000, Francis GALIEGUE wrote:
> Moreover, this situation is not very different from
> opening a file on disk and deleting it in another window. The only
> difference is that it'd be killed if the media is gone.
Yes, it is. Unlinked files are still there, still readable/writable/whatever.
If you don't know this sort of basic things - pardon me when I'm sceptical
about your suggestions regarding VFS.
> If well implemented, it needs no bad press, nor it needs press at all.
So where is your patch?
> > You missed one important thing: what to do with situation where system CAN
> > NOT be correctly detached (that is floppy can not be easily ejected). One
> > such situation is outlined above and it's just simples case ...
>
> And it has a simple solution: a forcible kill. After all, it's the
> users's fault in this case. You know which processes use a file, if
> this file doesn't exist *and* the device is "sloppy-mounted" and not
> here -> SIGKILL.
And what about kernel data structures affected by this stuff?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Francis GALIEGUE <fra...@mandrakesoft.com>
Subject: Re: Of removable devices
Date: 2000/02/15
Message-ID: <fa.iv3f3tv.si61oo@ifi.uio.no>#1/1
X-Deja-AN: 586173969
Original-Date: 15 Feb 2000 16:50:43 +0100
Sender: owner-lin...@vger.rutgers.edu
Original-Message-ID: <m3og9ib...@toy.mandrakesoft.com>
References: <fa.l8dhcfv.5nunb1@ifi.uio.no>
To: linux-...@vger.rutgers.edu
Original-References: <Pine.GSO.4.10.100021...@weyl.math.psu.edu>
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
Newsgroups: fa.linux.kernel
X-Loop: majo...@vger.rutgers.edu
Alexander Viro <vi...@math.psu.edu> writes:
>
> > Moreover, this situation is not very different from
> > opening a file on disk and deleting it in another window. The only
> > difference is that it'd be killed if the media is gone.
>
> Yes, it is. Unlinked files are still there, still readable/writable/whatever.
> If you don't know this sort of basic things - pardon me when I'm sceptical
> about your suggestions regarding VFS.
>
A file is backlinked to the fs superblock, isn't it?
> > If well implemented, it needs no bad press, nor it needs press at all.
>
> So where is your patch?
>
No patch. I simply wanted to ask whether it was possible, not "will it
be useful or not" because this is where the discussion has derived now
:(
> > > You missed one important thing: what to do with situation where system CAN
> > > NOT be correctly detached (that is floppy can not be easily ejected). One
> > > such situation is outlined above and it's just simples case ...
> >
> > And it has a simple solution: a forcible kill. After all, it's the
> > users's fault in this case. You know which processes use a file, if
> > this file doesn't exist *and* the device is "sloppy-mounted" and not
> > here -> SIGKILL.
>
> And what about kernel data structures affected by this stuff?
>
Hence my question to know whether it's possible or not...
--
fg
# rm *;o
o: command not found
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Alexander Viro <vi...@math.psu.edu>
Subject: Re: Of removable devices
Date: 2000/02/15
Message-ID: <fa.l9tnevv.67glb0@ifi.uio.no>#1/1
X-Deja-AN: 586210426
Original-Date: Tue, 15 Feb 2000 11:46:57 -0500 (EST)
Sender: owner-lin...@vger.rutgers.edu
Original-Message-ID: <Pine.GSO.4.10.100021...@weyl.math.psu.edu>
References: <fa.iv3f3tv.si61oo@ifi.uio.no>
To: Francis GALIEGUE <fra...@mandrakesoft.com>
X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majo...@vger.rutgers.edu
On 15 Feb 2000, Francis GALIEGUE wrote:
> Alexander Viro <vi...@math.psu.edu> writes:
>
> >
> > > Moreover, this situation is not very different from
> > > opening a file on disk and deleting it in another window. The only
> > > difference is that it'd be killed if the media is gone.
> >
> > Yes, it is. Unlinked files are still there, still readable/writable/whatever.
> > If you don't know this sort of basic things - pardon me when I'm sceptical
> > about your suggestions regarding VFS.
> >
>
> A file is backlinked to the fs superblock, isn't it?
Not. _Please_, read any introductory text on UNIX. Seriously. Files on
UNIX are nameless. Directories contain pairs (name, reference to file).
File may be referenced from any number of places. When you open it you
are getting a reference to file. Period. From that moment on names are out
of the game. Obviously, file can't be discarded if there are references in
directories or if somebody is using it. If you unlink the file you remove
the reference in a directory. It has _no_ effect on the file existence.
Now, if nobody uses it _and_ this was the last reference - fine, file can
be safely discarded (nobody will ever access it). Same for close(). Actual
discarding the file is a sort of garbage collection - it has _nothing_
with removing links to file.
Again, files do no sit in directories. They exist on their own.
And unlink() only removes a reference in a directory.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Francis GALIEGUE <fra...@mandrakesoft.com>
Subject: Re: Of removable devices
Date: 2000/02/15
Message-ID: <fa.irgn5tv.o6e7od@ifi.uio.no>#1/1
X-Deja-AN: 586222753
Original-Date: 15 Feb 2000 18:30:12 +0100
Sender: owner-lin...@vger.rutgers.edu
Original-Message-ID: <m3vh3qc...@toy.mandrakesoft.com>
References: <fa.l9tnevv.67glb0@ifi.uio.no>
To: linux-...@vger.rutgers.edu
Original-References: <Pine.GSO.4.10.100021...@weyl.math.psu.edu>
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
Newsgroups: fa.linux.kernel
X-Loop: majo...@vger.rutgers.edu
Alexander Viro <vi...@math.psu.edu> writes:
> >
> > A file is backlinked to the fs superblock, isn't it?
>
> Not. _Please_, read any introductory text on UNIX. Seriously. Files on
> UNIX are nameless. Directories contain pairs (name, reference to file).
[...]
I KNOW all this. I'm no beginner with Unix! What I see is that:
- task_struct contains files_struct
- files_struct contains struct file **
- struct file contains dentry *f_dentry
- dentry contains struct super_block *d_sb...
Therefore, with a file, you get a reference to a superblock...
--
fg
# rm *;o
o: command not found
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Francis GALIEGUE <fra...@mandrakesoft.com>
Subject: Re: Of removable devices
Date: 2000/02/16
Message-ID: <fa.ke0aolv.rnik0g@ifi.uio.no>#1/1
X-Deja-AN: 586490252
Original-Date: 16 Feb 2000 12:57:17 +0100
Sender: owner-lin...@vger.rutgers.edu
Original-Message-ID: <m37lg5m...@toy.mandrakesoft.com>
References: <fa.f0oilmv.k2ipb6@ifi.uio.no>
To: linux-...@vger.rutgers.edu
Original-References: <m3vh3qc...@toy.mandrakesoft.com>
<Pine.GSO.4.10.100021...@weyl.math.psu.edu> <ABK7Q...@khim.sch57.msk.ru>
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
Newsgroups: fa.linux.kernel
X-Loop: majo...@vger.rutgers.edu
"Khimenko Victor" <kh...@sch57.msk.ru> writes:
First, sorry for yelling earlier. I'm conscious of problems with PC
floppies. Calling block_fsync() regulary is not even a solution, I'm
aware of this as well - too much overhead for not so much. But a
newbie is not as stupid to eject a floppy when he sees the LED is on
(well, at least I hope so :)
> Yes, this all can be changed. You will need "just" rewrite half of
> VFS layer to do it. Current VFS implementation does not allow sane
> supermount. Yes, you can cook up something (it was even done). It'll
> work sometimes. But it'll ruin floppies from time to time. MS DOS
> doing it, Windows doing it (there are no easy way to check if
> filesystem is clean and you can eject floppy safely -- I've ruined
> my floppies pretty often on old days when I've used them) but WHY
> THE HELL Linux should do this is well ?
>
I don't want Linux to thrash floppies... The media thrashes itself
more easily than Linux does... And I know that the MS_SYNCHRONOUS
option only works for ext2 for now, whereas most floppies are FAT...
The big problem is that mounting/unmounting is not possible if the
mount point is currently being busy. With the current VFS
implementation, the superblock pointer in a dentry cannot be changed
if the dentry is in use. So yes, you're right, it requires that half,
if not more, of the VFS be rewritten :( I'll have a deeper look at all
this to identify all possible problems.
kfm has no problem with automount (unlike MC) because it reads a
directory but does not chdir() to it, so yes, kfm, unlike MC, will
allow the "click icon/remove media (after timeout)/click refresh"
cycle. But kfm is only one application among thousands.
--
fg
# rm *;o
o: command not found
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: "Theodore Y. Ts'o" <ty...@MIT.EDU>
Subject: Re: Of removable devices
Date: 2000/02/16
Message-ID: <fa.g6hssmv.11k8t8d@ifi.uio.no>#1/1
X-Deja-AN: 586548410
Original-Date: Wed, 16 Feb 2000 09:45:10 -0500
Sender: owner-lin...@vger.rutgers.edu
Original-Message-Id: <2000021614...@tsx-prime.MIT.EDU>
References: <fa.ke0aolv.rnik0g@ifi.uio.no>
To: Francis GALIEGUE <fra...@mandrakesoft.com>
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
Phone: (781) 391-3464
Newsgroups: fa.linux.kernel
X-Loop: majo...@vger.rutgers.edu
From: Francis GALIEGUE <fra...@mandrakesoft.com>
Date: 16 Feb 2000 12:57:17 +0100
"Khimenko Victor" <kh...@sch57.msk.ru> writes:
First, sorry for yelling earlier. I'm conscious of problems with PC
floppies. Calling block_fsync() regulary is not even a solution, I'm
aware of this as well - too much overhead for not so much. But a
newbie is not as stupid to eject a floppy when he sees the LED is on
(well, at least I hope so :)
Right. That was the basic design behind supermount, as I understand
it. Users have been well programmed that if the LED light is off, it's
safe to pop the disk out. Because Linux normally has different rules,
this violates the principal of least surprise.
So the question is whether it's possible to do something relatively
painless which allows the right thing to happen under most
circumstances. A key observation is that the sort of programs you
expect naive users to use: i.e., cp, office suite software,
etc. generally tends to open a file for writing, write it out
completely, and then close the file. So if you can automatically
dismount the filesystem after the close, and then automatically mount
the filesystem after something tries to touch the dentry, it works 99.9%
of the time. Is it perfect? No! Is it better than hoping that users
will adapt to Linux? Well, that's a religious question, but the
traditional answers is that users are (a) resistant to change and (b)
highly stubborn, and so it's better to try to make at least some
consessions to pre-programmed behaviour.
By the way, ext2 has a serial number, so it *would* be possible to make
ext2 check the superblock parameter when it was informed that a media
change may have happened. So it's not just the FAT filesystem that can
do this.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: David Balazic <david....@uni-mb.si>
Subject: Re: Of removable devices
Date: 2000/02/16
Message-ID: <fa.cg6jf1v.jm8lq2@ifi.uio.no>#1/1
X-Deja-AN: 586630684
Original-Date: Wed, 16 Feb 2000 20:39:31 +0100
Sender: owner-lin...@vger.rutgers.edu
Content-transfer-encoding: 7bit
Original-Message-id: <38AAFCF2...@uni-mb.si>
To: linux-...@vger.rutgers.edu
X-Accept-Language: en
Content-Type: text/plain; charset=iso-8859-2
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majo...@vger.rutgers.edu
To add my own $0.02 ...
The situation with removable devices is pretty bad. Redhat 6.x has TWO
packages to "solve" it. They are magicdev ( part of GNOME ) and autorun
( KDE ).
I observed their work with CDs , I don't know if they support floppies
too.
autorun/magicdev is started when the KDE/GNOME desktop is started (
startx or
xdm/kdm/gdm login ). They both wait for an inserted CD and then mount it
and
optionaly run the file /<cd-mount-point>/autorun .
They unmount and eject the CD when the :
- eject command is executed
- user clicks on "eject" in the context menu of the CD-drive icon
- maybe some other cases I don't know
autorun also doesn't lock the drive so the user can eject it manually.
When that is detected autorun unmounts the CD ( if it is not in use,
if it is, shit happens )
Now my opinion is that both programs suck. The automatic execution of
the autorun file is stupid IMHO ( altough beginner may like it ).
Second the mounting functionality can be done (better?) by autofs.
I recomend/propose/use the following.
Let autofs mount the CD on access ( it makes no sense to mount it, if it
won't be used ). Configure a short umount period ( 5 secs , or even less
),
so the user can eject the CD by pressing the cd-drive's eject button
shortly
after finishing using the CD.
The door should be locked while the CD is mounted.
This solution works pretty well.
It is clean ( IMHO ).
Doesn't require extra software.
No danger of any corruptions. ( of kernel structures , like when the
medium is
ejected while still mounted ).
Problems :
if the CD is unmounted ( due to timeout ) and then later accessed again,
the CD
is first spinned up ( my drive has a 10 sec timeout for spin-down ) and
something
is read from it. This takes about 5 secs and happens for even the
smallest access,
like "cd /auto/cd". It seems that the kernel driver checks if the medium
is still
the same which contents are cached.
( this is kernel 2.2.14 , ATAPI cdrom on /dev/hdc , type TEAC CD532E-B
).
For automatic program start ( for those who want it ) a simplified demon
might be used :
for(EVER){
wait_for_CD_insertion(); /* code can be ripped from magicdev or
autorun */
system(CD_PATH "/autorun"); /* autofs will mount it for us */
}
I also played with the idea to mount the CD when it is inserted, then
wait for either :
- /bin/eject is called
- some GUI equivalent to /bin/eject
- user press the EJECT button on the drive (*)
and the either unmount it and eject it, or ,if unmount is not possible
, either do
nothing or inform the user that the CD can not be ejected , because it
is in use.
(*) - this is the problem. Even if both ATA and ATAPI standards specifiy
a method
of infroming the host that the eject button was pressed, my cd-rom drive
does not
support any method for that ( or I couldn't figure it out ).
I believe that 99 % of all ATAPI CD-ROM units ( situation with SCSI may
be better,
but I wouldn't bet my hat on it ) fail to support this.
So I dropped this idea.
As for floppies:
The autofs approach has the following problems :
Eject can not be prevented, so at least the following must be done :
- for read-only floppies : somehow unmount it , even if it is in use
is this possible ?
or maybe hide it from further access , return some error to apps that
have open files on it and try to read from them, and when the last user
terminates , unmount it for good.
- r/w floppy :
- ( for caching ) if there is dirty data in caches, start writing them
immediately , so that the drive LED is on and the user won't eject
it.
- same as for r/o access ( hiding and returning errors for further use
)
Another possibility : somehow keep the LED on as long as the drive is
mounted.
Hope some of my babbling made sense :-)
--
David Balazic
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox <al...@lxorguk.ukuu.org.uk>
Subject: Re: Of removable devices
Date: 2000/02/16
Message-ID: <fa.g04j37v.v4ur93@ifi.uio.no>#1/1
X-Deja-AN: 586645490
Original-Date: Wed, 16 Feb 2000 19:04:37 +0000 (GMT)
Sender: owner-lin...@vger.rutgers.edu
Original-Message-Id: <E12L9kd-...@the-village.bc.nu>
Content-Transfer-Encoding: 7bit
References: <fa.cg6jf1v.jm8lq2@ifi.uio.no>
To: david....@uni-mb.si (David Balazic)
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majo...@vger.rutgers.edu
> autorun also doesn't lock the drive so the user can eject it manually.
> When that is detected autorun unmounts the CD ( if it is not in use,
> if it is, shit happens )
Thats actually a kernel bug, its now fixed. The door stays locked
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: David Balazic <david....@uni-mb.si>
Subject: Re: Of removable devices
Date: 2000/02/16
Message-ID: <fa.deakcvv.1rlajrr@ifi.uio.no>#1/1
X-Deja-AN: 586661042
Original-Date: Wed, 16 Feb 2000 20:09:07 +0100
Sender: owner-lin...@vger.rutgers.edu
Content-transfer-encoding: 7bit
Original-Message-id: <38AAF5D3...@uni-mb.si>
References: <fa.g04j37v.v4ur93@ifi.uio.no>
To: Alan Cox <al...@lxorguk.ukuu.org.uk>
Original-References: <E12L9kd-...@the-village.bc.nu>
X-Accept-Language: en
Content-Type: text/plain; charset=iso-8859-2
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majo...@vger.rutgers.edu
Alan Cox wrote:
>
> > autorun also doesn't lock the drive so the user can eject it manually.
> > When that is detected autorun unmounts the CD ( if it is not in use,
> > if it is, shit happens )
>
> Thats actually a kernel bug, its now fixed. The door stays locked
Huh?
I thought that it was a feature of 'autorun' to enable ejecting of CDs
"like in windows" ?
Is that removed now or what ?
( Im not missing it, just wondering )
--
David Balazic
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/