>> However, the problem is that if you eject a disk before unmounting it,
>> sometimes you get a nice frightening "kernel panic" error (even when being
>> careful enough to wait for the floppy light to go off). On one occasion,
>> putting the disk back in didn't help, and I had to reboot!
>>
Paul> The last time i've seen this was when i was running the 1.2.13 kernel
Paul> and with installation of Debian-1.1.6 with the most current kernel these
Paul> problems have virtually vanished.
I confess this worrisome experience is rather old. Well, I had it once more
recently, but I cannot swear it was after I upgraded to 2.0 kernel
>> I was also surpised that Linux was not that much better than DO$ for the
>> multitasking of floppy formatting: the system stops responding, and if you
>> then eject the disk...
>>
Paul> Are you sure you're running Linux? ;-) Even with older 1.2.13 kernels i
Paul> always had this multitasking working when formatting or copying
Paul> floppies. Maybe you got some broken hardware!
Well, again this is probably fixed by now, if you say things improved in this
respect. What I had was only occasionnaly a long freeze, but I always could
completely garble my X screen by quickly switching between windows, or
switchiung between pulled-down emacs menus (not the most robust piece of X
programming, I guess). This was during either a fdformat or mformat, I don't
remember. But it is true that now under kernel 2.0, it seems to have
disappeared. Good! One worry less!
Concerning mtools (3.0.3), mdir fails to read the fat of most floppies I
receive, presumably it cannot read vfat filesystem:
~/$ mdir
Bad FAT for drive A, trying secondary copy
Could not read FAT for A
Cannot initialize 'A:'
This is why I stopped using it. If I format using mformat, then I can mdir,
etc... I suppose this is just msdos filesystem then.
Anyway, since my biggest worries about the use of floppies are apparently
outdated, what about my little worries.
1) How to prevent a user to prematurely eject a disk before sync is over?
Mounting with the sync option is not enough: that's the way I do it, and still
the fd light goes off before the file is truly written to disk (and umount or
sync gets it on again).
2) Is there a way to detect this and gracefully recover?
3) Is there any way to force a disk change when an application accesses
/floppy? To the user, this is not quite transparent, as the error message
gives no clue about which application is blocking.
I'm just asking because I need to set up an idiot proof access to /floppy. The
current situation is nearly idiot proof in that idiots will hardly manage to
use (format, read, write) floppies anyway...
Ah, and consider myself as idiot in chief: last time I tried to format a floppy
on a Win95 machine, I ended up bruising the Ctrl-Alt-Del key a few times: this
is the only thing that responds when you start wondering what this bloody
machine is doing to your disk after half an hour...
Amities,
Jean Orloff
+++++++++ + + + + + + + ++++++
+Tel:(33)50.09.16.75 Fax:(33)50.09.94.95 http://lapphp0.in2p3.fr/~orloff/ +
+++++++++ + + + + + + + ++++++
In a Belgrade hotel elevator:
To move the cabin, push button for wishing floor. If the cabin
should enter more persons, each one should press a number of
wishing floor. Driving is then going alphabetically by
national order.
+++++++++ + + + + + + + ++++++
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
