Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.wizards Subject: Re: Two identical filenames in one directory! Message-ID: <2516@auspex.auspex.com> Date: 29 Sep 89 23:55:41 GMT References: <22@minya.UUCP> Reply-To: guy@auspex.auspex.com (Guy Harris) Organization: Auspex Systems, Santa Clara Lines: 82 >This is the "vertical" hexdump format, where each character in a vertical >3-byte slice. Thus byte 195 is 'c' which is 0x63. You all realized that >this was Sys/V without needing to be told, of course, as soon as you saw >this dump. Or, at least, some system with the V7 file system, such as S5.... >On earlier versions of Unix, I'd know instantly what to do. It's easy enough >to write a program that runs thru a directory and extends each null byte to >the end of the entry. But on Sys/V, this doesn't work, because nobody, not >even root, can write a directory. And on earlier versions, root *can* write a directory? Wrong. The only way "root" can write a directory - on V6, V7, S3, S5, or 4.xBSD, or on most if not all UNIXes derived therefrom - is to open the raw disk and stomp on the file. If you could do it on some system that purported to be one of the above, somebody must have hacked it. >I might observe that this is a clear violation of the principle that sofware >should be conservative in what it produces and liberal in what it accepts. >Sys/V allows the creation of such a directory entry; the proof is >above; More correctly, System V doesn't *dis*allow the creation of such directory entries by all possible creators of such entries. Since one such potential creator is generally known by the name "disk controller", it would be a bit hard for it to do so - ultimately, it has to trust the controller either not to screw up, or to report I/O errors if it does. Other possiblities include bugs in the file system code, or bugs in "fsck" (yes, there was a bug in "fsck" that could cause it to create entries of that sort, although as I remember those entries were created when orphaned files were reattached to "lost+found", so that's not the problem here. >it should properly handle references to them. And how would you suggest that it do so? Allow null bytes in the middle of path names? :-) >I might also make nasty remarks about the folks who decided that this >sort of thing couldn't happen, so they didn't have to allow root to >open directories for writing. I might even make comments about people >who add code to kernels that does nothing productive; it just wastes >cycles preventing me from doing something I want to do. I'm sure Ken and/or Dennis would be glad to hear them, although they might point out that preventing even the super-user from writing to directories reduces the chances that a user *would* create a screwed-up directory. It's unfortunate that a file system bug or disk controller problem can cause damage that can't be repaired easily, but that's life. >Does anyone know a solution to this problem, short of zeroing the >directory, running fsck, and reinstalling from backup? The best way >would be to say "Yes, root can write a directory; here's how..." No, root can't write a directory, which has, as noted, been the case since time immemorial (if you remember otherwise, you might want to get your memory adjusted for distortion). However, there are a couple of possibilities: 1) Make a new directory to hold all the files in question, move all there (except, obviously, the one with the trashed directory entry), "clri" the inode for the directory containing the trashed entry, and then "fsck" the file system. This will cause the blocks of the directory containing the trashed entry to be returned to the free pool, the directory entry for that directory to be reamed out, link counts to be adjusted appropriately and should result in the file with the trashed entry getting reconnected in "lost+found"; you can then move it somewhere else, if you want. Then rename the new directory to have the same name as the now-defunct directory. 2) Dive in with "fsdb", if your system has it, and patch the directory. Me, I'd go for 1) if possible. Patching raw file systems may be loads of fun, but I'd rather get my fun elsewhere.... "fsck" should check for this, and fix it somehow; unfortunately, it doesn't.