>unprotecting:
>
>gek:~# fdformat /dev/fd1
>ioctl(FDGETPRM): No such device
>
>doing this repeatedly gets the same result (the disk I was using was a=
lready
>formatted (1 min before) so I don't think it's a problem of detecting =
floppy=20
>type).
Yes, it is a problem with detecting floppy type, and yes, this is
intentional too. Floppy type detection isn't triggered by a formatting
command, because this would take an unduly long time on an unformatted
disk (which is, after all, the most common situation in which you want
to format a disk :-) ).
> fdformat /dev/fd1H1440 will, however works as expected. After a succe=
sf
>ull
>fdformat /dev/fd1H1440, fdformat /dev/fd1 will work.=20
>
> - hitting ^C while fdformat will get me a page of numbers :) with th=
e
>floppy driver state and on the final lines I get a floppy timeout and
>unexpected interrupt. (I can send a full report if interested)
I agree that these are somewhat confusing. These messages are due to
the fact that the same routine is used to handle timeouts (where
debugging info is useful) and interruption of system calls by the user
(where debugging info is not appropriate). I fixed this in the patch
at=A0ftp.imag.fr:pub/Linux/ZLIBC/floppy/BETA/fdp-1.3.84-0704.diff.gz=A0=
.
A single "floppy0: unexpected interrupt" message is still left, which
is not too loud IMHO.
> - I cannot strace fdformat ... I also get the forementioned page wit=
h
>numbers :) and fdformat also says: ioctl(FDFMTTRK): Interrupted system=
call
This one works fine for me (in 1.3.84, floppy driver with and without
the new patch).
>
> Did anyone notice these or I'm inventing things ?=20
>
> Matei
>
Alain