> > This should not happen! In the case of the Zip drive, the driver should
> > implement a timeout after which it returns an error to the process.
>
> Hmm, a good idea, but what if the disk was somehow changed (I don't have
> a Zip, so I have no idea if this is possible -- I assume the disk eject
> button is electronic rather than mechanical, but know nothing beyond this).
The button is electronic, but I don't know whether there is a method to
lock the disk in the drive through software.
> Hmm, last time I tried this was back in 1.1.x days, but wasn't willing to
> try it again. :) A cursory examination of floppy.c shows it is interrupt
> driven, so timeouts would have to be done by semaphores and such like, I
> would imagine. The problem of knowing what diskette was in the drive
> still remains: the layered methodology might prevent the driver from
> knowing anything specific about the filesystem to tell it what disk is
> present (eg. serial numbers, etc.).
Remember those VFS: Disk change detected... messages? The floppy drive has
a "disk change line" that makes it possible to detect if a floppy has been
changed between the last read/write operation and the current one. The
kernel already checks the state of this whenever it does a read or write
to the physical disk. I would expect there to be similar functionality in
the Zip drive. So we can use the hardware to detect whether a disk change
has occurred; we don't need to resort to checking serial numbers.
What the kernel needs is a generic method of detecting when any type of
removeable media is removed or changed, and acting accordingly.
This should also extend to hard disks that have gone south, which was the
problem the original poster was experiencing.
+-----------------------+---------------------------------------+
| Nathan Bryant | Unsolicited commercial e-mail WILL be |
| nathan@burgessinc.com | charged an $80/hr proofreading fee. |
+-----------------------+---------------------------------------+