Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.xenix
Subject: Re: Confused file name in directory
Message-ID: <5587@mimsy.UUCP>
Date: Wed, 25-Feb-87 13:03:12 EST
Article-I.D.: mimsy.5587
Posted: Wed Feb 25 13:03:12 1987
Date-Received: Fri, 27-Feb-87 23:26:54 EST
References: <105@aob.UUCP> <563@aw.sei.cmu.edu.sei.cmu.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 57
Xref: utgpu comp.unix.questions:1184 comp.unix.wizards:1126 comp.unix.xenix:116

In article <105@aob.UUCP> someone finds a directory entry with an
embedded NUL, and has nothing handy to fix it.

In article <563@aw.sei.cmu.edu.sei.cmu.edu> pdb@sei.cmu.edu (Patrick
Barron) writes:
>As a last resort you could use 'clri' on the inode associated with that
>file (use 'ls -li' to find the inode numner).

This will indeed make fsck clear the directory entry, but will also
lose the contents of the file.  If there is another link to the
file, it can be copied first, but if not, there are other ways.

The problem is in the directory itself, not in the file; so you
can clri the directory inode, and fsck will put any orphaned files
in the lost+found directory.  This will lose the names of each of
the inodes, but these can be saved first:

	# ls -li <bad_dir> > dir_list
	# clri <inode>
	# umount <drive>
	# fsck <drive>
	# mount <drive>
	# cd <lost+found_area>
	# mkdir <bad_dir>
	# sh <script> <bad_dir> < dir_list

where `script' reads name/inode pairs out of a directory and `mv's
the file `#<inode>' (six digits) to $2/<name>.

Note that any files with other links will not be placed in lost+found,
and must be re-linked `by hand' later (after tracking them down
with ncheck).  Also, make sure there is enough directory space in
lost+found for all the files that will be orphaned, if necessary
by augmenting the mklost+found shell script.

There is still another way, easier yet but more dangerous and
thrilling.  You cannot edit a directory, but you can edit a file.
And the only difference between the two is one byte.

Using the source to clri, ---you say you have no source?  Ah well.
Perhaps if you ask nicely, your vendor will help.  I would not
count on it.  Source is better.  ---Using clri.c, or your magical
knowledge of file system formats, write another program, `hacki'.
Instead of zeroing the inode, toggle the S_IFDIR and S_IFREG bits.
Run it once on the directory inode, and now it is a file.  Use your
favourite binary editor (Emacs works, but be sure it does not make
a backup!), fix the embedded NUL character.  Make sure the file size
is exactly the same as before.  Then run the hacki program once
more.

(I did this once on a 4.1BSD system.  It worked quite well.)

Of course, if you have source, you could alter fsck to check for
embedded NULs in filenames.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu