Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!unido!uniol!lehners
From: lehners@uniol.UUCP (Joerg Lehners)
Newsgroups: comp.unix.wizards
Subject: Re: Two identical filenames in one directory!
Message-ID: <872@uniol.UUCP>
Date: 28 Sep 89 23:49:49 GMT
References: <22@minya.UUCP>
Organization: University of Oldenburg, W-Germany
Lines: 77

Hello !

jc@minya.UUCP (John Chambers) writes:
>Hi, folks.  Here I am again with another puzzle.  You might recognize
>the following output:
>[lots of problem describing text deleted]
Well, I would have done the same things to determine the problem.

>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.  
Hmmm .. I started working with Unix with System V.2, now I use
System V.3 and sometimes SunOS.
But it never was possible to write on directories, even not as root.
Suppose something like 'ls > blah' when 'blah' ist a directory !

>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; it
>should properly handle references to them.  I might also make nasty remarks 
Hmmm .. I don't believe that this offending file was created due to
'normal' kernel operation. Maybe I'm wrong, but I can't imagine a program
that would create such file names.
I think, it was a software or hardware flaw that caused some disk-write
do malfunction.
I once rebootet one system here (System V.3) and discovered some
defective directories. These directories had garbage in the first
three directory slots ('.' and '..' were lost, even on '/etc').
But I discovered too, that this was due to wild disk writes of the
kernel just before the crash. It took some time to clear the things
up, but it worked.

>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.  But 
>I won't.  I'll just ask:  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..."

I can image 3 possiblitities:

a.) If you have fsdb (File System DeBugger, it's located in /etc here)
you can do formatted reads and writes on inodes, files and directories
thru the disk file (raw or block device). It's dangerous, but it works.
There should be a manual to lookup the details.

b.) Move all 'accessible' files out of the directory with the offending
file and do 'unlink <dir>/..', 'unlink <dir>/.' and 'unlink <dir>' above
that directory with '<dir>' replaced by the directory name.
This is just what rmdir does, but without all the checks. unlink resides
in /etc on the systems here. Do it as root of course.
The kernel should throw away the now not connected directory (because
the unlinks made to link count zero).
Next run fsck, it should reconnect the offending file to the lost+found
of the partition. The new file name is composed from the i-node number.
(it works at least here, I tried it).

c.) Back up all the files with tar or cpio and restore all except
the offending file (maybe the offfending file isn't backed up at all).

Well, and all 3 possibilities don't need writes on directories.

>Alternatively, I guess I could try to find a pirate copy of the source to
>fsck, and add this to its repertoire.  It'd probably only take an hour or
>two.  Ain't binary-only systems nice?
Yes .. It would be nice to have the source for fsck. At least the fsck
here has a flaw: it does not detect wrong or missing '.' and '..'
entries of directories.

  Joerg
--
/ Joerg Lehners                       | Fachbereich 10 Informatik ARBI   \
|                                     | Universitaet Oldenburg           |
| BITNET/EARN: 066065@DOLUNI1.BITNET  | Ammerlaender Heerstrasse 114-118 |
\ UUCP/Eunet:  lehners@uniol.uucp     | D-2900 Oldenburg                 /