Two identical filenames in one directory!

[Guy Harris]

>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.