Urgh.  This is definitely the kind of error I wanted least to show up.

The floppy driver is the least mature part of the system, and any errors

are likely to show up there.  I'm unable to reproduce this error: the

only way this kind of write error could occur is if the floppy driver is

totally unable to read the first block.  Normally write errors won't be

noticed by the writing process: it just writes to the cache. 
This definitely looks like a driver bug: UNLESS you are using floppies

that aren't formatted? You have to format the floppies (currently

possible only under DOS) before trying to write to them.  Please, please

tell me that was the reason :-)
Is somebody else getting this same kind of error? Could you please

report the hardware you are getting it on (5.25"? 3.5"?)? Are you able

to read the disk (as a root-image for example), and does the error
Yeah, I'm lazy. It's much easier to do a simple "reply", so that the

person with the problem gets it solved, but nobody else. I'll try to

reply to the mailing list in the future (unless it's something very

machine-specific.)
This is a possibly deficiency in the linux kernel.  I don't allow

links/unlinks to directories, as keeping track of the parent is too much

work.  I /think/ it's impossible to allow a hard link to a directory,

but I'm not sure.  Anybody with ideas is free to mail me. 
I think the best solution is to write a "mvdir", which simply copies the

directory and removes the old one. Obviously I haven't done it. (Does

minix allow hard links to directories? How does it handle the '..' file
Most programs starting with a "g" are GNU software.  This is also the

case with "gar".  Gar is just a shorthand fro "GNU ar", ie "ar" ie

"/usr/local/lib/gcc-ar".  Likewise "gstrip" is the same as strip, "gas"

is the same as "as" etc. I have most of the gcc binaries linked to three

different names: /usr/local/lib/gcc-xxxx, /usr/local/bin/xxxx and

/usr/local/bin/gxxxx. 
chmem is a Minix brain-damage.  Ignore it.  It isn't...
[ message continues ]

Date: Sun, 10 Nov 1991 18:09:31 +0200

   From: Linus Benedict Torvalds <torvalds@cc.helsinki.fi>
   darken.@cs.yale.edu:

   > 1)  mv doesn't seem to move directories properly.  It looks for

   > something called mvdir and dies.  I want to fix this right away,

   > so I'm goin to start working on it unless one of you drops me a

   > line and explains what stupid thing I've done.
   This is a possibly deficiency in the linux kernel.  I don't allow

   links/unlinks to directories, as keeping track of the parent is too much

   work.  I /think/ it's impossible to allow a hard link to a directory,

   but I'm not sure.  Anybody with ideas is free to mail me. 
Actually, some friends and I spent a lot of time discussing the very

topic tonight.  What we basically got out of it was this:  1) Allowing

links and unlinks to directories are a bad idea; it can potentially

completely ruins the fundamental assumption that the filesystem is a tree.

2) The right way to do this is with the (as yet unimplemented) rename

call.  However there are a number of interesting locking issues that

come when you try to implement this cleanly.
There are a couple problems which rename has to check.  If it is moving

directories around, then the source directory must not be a parent of

the destination directory.  (If it were, there would be no way of

referencing that part of the filesystem after the rename.)  It could

check to make sure this was the case, but unless you actually lock the

directories against another move, there could be a race condition which

could cause the source directory to be a parent of the destination

directory after the check but before the actual reaneme operation, and

bad thing would happen.  There are also other race conditions (not as

sexy) that happen when two processes try to rename a directory at the

same time, and when an rmdir attempts to remove an otherwise empty

destination directory.  
We talked about trying to fix this problem by adding a minimal set of...
[ message continues ]