Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!nbires!hao!noao!mcdsun!nud!df
From: df@nud.UUCP
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.xenix
Subject: Re: Confused file name in directory
Message-ID: <259@nud.UUCP>
Date: Thu, 26-Feb-87 16:52:22 EST
Article-I.D.: nud.259
Posted: Thu Feb 26 16:52:22 1987
Date-Received: Sun, 1-Mar-87 10:11:34 EST
References: <105@aob.UUCP>
Reply-To: df@nud.UUCP (0000-Admin(0000))
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 22
Xref: utgpu comp.unix.questions:1214 comp.unix.wizards:1160 comp.unix.xenix:128

In article <105@aob.UUCP> jim@aob.UUCP (Jim Anderson) writes:
>I have an Altos 2086 running XENIX 3.2f.  I had a problem show up recently
>that defies all my attempts to fix.  What has happened is that a file name
>in a directory has a null in the middle of the name.  The file is actually
>the name of a directory.  The name used to be 'Doc', but is now 'D\0c'.

I don't know how the null got into your directory entry in the first
place, but to fix it you will have to use fsdb or a similar tool to
change the name in the directory entry through a mechanism outside the
bounds of the normal file access system calls.

The kernel routine namei (which associates filenames to inodes) can be
blamed for making recovery difficult.  It takes the null terminated file
name that you pass it, adds additional nulls to the end to make it a
total of 14 bytes in length, then compares *all* 14 bytes with the name
in the directory entry.  This makes it impossible to match a directory
entry with a null embedded in the name.  (Of course, the null *can't*
possibly get there in the first place :-))

Namei works this way on System V up to and including System V.3.

-Dale

---
Dale Farnsworth (NO7K)			seismo!noao!mcdsun!nud!df
(602)438-5739				ihnp4!mot!nud!df