MBPPXMH@cms.manchester-computing-centre.ac.uk (08/22/90)
- - - - - - - - - - Start of forwarded note - - - - - - - - - - Whilst backing up a hard disk partition. I discovered the following. Logged on as root I was able to rmdir a directory that had a filesystem mounted to it, (I was expecting a directory busy message). I then did umount device (/dev/hd2) and mkdir [old directory], mount device, to find that the device (/dev/hd2 !!!) was no longer a valid filesystem. Sorry if this is old news, I've not been reading the newsgroup recently. p.s. Running PC Minix V1.5.10 Mike Holme Dept Pharmacy, Univ Manchester. England
archer%segin4.segin.fr@relay.prime.com (Vincent Archer) (08/22/90)
MBPPXMH@cms.manchester-computing-centre.ac.uk says: >Whilst backing up a hard disk partition. I discovered the following. >Logged on as root I was able to rmdir a directory that had a filesystem >mounted to it, (I was expecting a directory busy message). I then >did umount device (/dev/hd2) and mkdir [old directory], mount device, >to find that the device (/dev/hd2 !!!) was no longer a valid filesystem. >Sorry if this is old news, I've not been reading the newsgroup recently. >p.s. Running PC Minix V1.5.10 Stop me if I'm wrong :-), but I think your bug comes from this: - Your mounted file system was empty. - Therefore, the directory you mounted this file system on was empty (logical) (let's call this ~/mounted for clarity's sake) - Therefore, you're able to do a rmdir on it. - rmdir removes first the link between ~/mounted/. and ~/mounted. As a result, ~/mounted does not contain a valid "." entry anymore... - rmdir then removes the link between ~/mounted/.. and ~ (whatever this is). As a result, ~/mounted does not contain a valid ".." entry anymore. - rmdir then removes the entry ~/mounted from ~. This is legal (since the directory is empty). However, the inode (on the initial disk) is still referenced (from mounted table), so it is not purged. This is irrelevant anyway. - You asked to remove a device, whose super-block was in the mounted table; that is legal. Never bother that the directory associated no longer exists, there's no check there. Since you umount, the inode (left dangling at the previous step) is no longer referenced, and now is freed. - You create a directory. No problem here. - You request a mount. FS checks the file system, and find that the root inode on the mountable file system is awfully wrong: (no ".", no "..", and) the inode is free! Obviously, this doesn't refer to a valid system, and the fact that FS found a super block is just a coincidence :-) Well anyway, the fix to this is quite simple: rmdir() should be forbidden to work on inodes that exists on the FS mount table. Such a case should return the same code as a non-empty directory. Vincent Vincent Archer | Email:archer%segin4.segin.fr@relay.prime.com "People that are good at finding excuses are never good at anything else"
MBPPXMH@cms.manchester-computing-centre.ac.uk (08/22/90)
I know very little about minix below the systems calls level, so I can't say if what you say is right or wrong, though it sounds plausable. However you were right to say that my filesystem was empty. Is this a bug then. I haven't tryed it with UID>0. Should the superuser know better or should it be d disallowed for superuser also ? Mike Holme Dept Pharmacy, Univ Manchester (Not for much longer though thank god).