[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Floppy management?



 >> 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
debian-user-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: