Two identical filenames in one directory!

[John Chambers]

Well, lots of followup on that one; time for a summary.  As was my
fear, nobody told me how to write to a directory in Sys/V.  I suspect
that it can't be done.

Lots of people suggested writing to the raw device, implying that this 
is the same thing as writing to a directory on the device.  I don't 
think I'm picking any nits when I object that it's not the same thing
at all.

On the other hand, it's exactly what I've done.  Shortly after posting
the article, I bit the bullet, put my shoulder to the grindstone, and
lots of other cliches, and the result was a little program that groveled
through the filesystem, showing me what's there.  A couple of hourse
later, I added a routine to scan directories for funny-looking entries,
and if a -c option (for "changes allowed) was on the command line, make
some judicious changes.  It was sorta fun working on a live filesystem
(with lots of syncs), and watching it all work the first time....

I saw quite a few suggestions like:

> What happens if you do the following:
> 
> tar cf - . | ( cd someplace_else ; tar xf - )
> 
> I.e. use tar to shift the whole directory structure someplace else.
> However, I'm still not 100% sure how you'd set about removing both
> entries in the original directory, rm might still do ugly things.

Good guess.  You get a "not found" message from the first tar, and the
copy works otherwise.  The offending directory entry is still there; 
commands like rm won't touch it (because it can't be opened).

The most curious aspect is that the common suggestion (clri/fsck) didn't
clear up the problem.  I could get the directory renamed as something in
the lost+found directory; I couldn't get fsck to rename the garbage entry.
I'm not too clear on just what fsck did with the zeroed inode that used
to be the file's data; the bad directory entry was still there, but with
size 0.  

I'm reminded of some advice a read years ago, to the effect that, when 
faced with alternatives, one should avoid choosing the worst.  In this
case, clri+fsck tossed out the data, but kept the garbage directory entry.

> If I were a _REAL_ hacker, I'd suggest opening the raw disk device
> (/dev/rsm0g or whatever) for UPDATE, seeking along it looking for
> the string "active", and then just patching the disk itself. [1]
> I do this on a fairly regular basis to my machine at home, but then
> the file structure of CP/M is a bit simpler that UNIX :-)

Well, I guess I'm a real hacker, because that's what I did, and it
wasn't all that hard.  It took a bit of paranoid coding, because there
were numerous ambiguities in the manuals, and a few real strangenesses.
(Who ever got the bright idea to make the inode table 1-based? ;-) 
But now I have a little program that zips around a Sys/V filesystem,
and I can hack it up to do interesting things...

> [1] This is not meant to be taken totally seriously, I'd suggest
> waiting to hear what flames people have for such a brutal idea
> before trying it. Also sync the disk, and umount it before
> attempting this.

Maybe you weren't serious, but lots of others seem to think this is
a reasonable way to solve problems.  Maybe I'm paranoid, but I don't
agree.  On the other hand, it gives me more "Unix internals" that I
can put on my resume, and that's worth a lot in today's market, so
perhaps I shouldn't complain.  I mean, if people will pay me more to
solve problems that way than they will to work at a higher level, who
am I to criticise or refuse the money?

-- 
#echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:'
echo '	John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)'
echo ''
saying