Funny filenames: in the nick of time!
LongoMR
mrl at drutx.UUCP
Fri Jun 28 15:54:27 AEST 1985
>> Thanks for all the replies; I'll summarize here and add a wrinkle.
>> Basically, if you have file names with the eighth bit set, then nothing
>> except a clri followed by a fsck will get rid of it.
not true. I originally replied with this one by mail, but wasn't
too specific. You can edit the directory entry with fsdb, if you have it.
Here's the procedure:
+ as root, envoke fsdb with the block device name of the file system
as an argument
+ print the directory inode containing the bad file name
(ex. if the file name is /usr/bin/<garbage> and the inode number
of directory /usr/bin is 500, type "500i" to see the inode)
+ look at the directory entries 1 at a time until you find
the bad file.
"f0d" will list the 0th block in directory format
"f1d" will list the next block, etc.
Each entry will be proceded with a d[number].
+ change the name of the file by typing
d[number].name=new_file_name
(ex. d3.name=XXX1)
+ exit fsdb with a ^D or quit
+ remove /usr/bin/new_file_name
(in the above example use "rm /usr/bin/XXX1")
I know this works on AT&T Unix since I have been using it for years. I am
sorry that I can't say I am as certain that it works on Berkeley Unix. I
would be curious to know whether or not it does.
BTW - It is possible to create file names which cannot be
refered to by the shell in AT&T Unix. It is usually accomplished
by accident when garbage is given to a file descriptor
name within a c program. If the eighth bit is set
and you use any command to the shell, the shell will expand the
name to a string containing only 7 bit ascii characters. When
this name is fed to the command, the kernal will recognize the eighth
bit and come up with a non-match. The usual sequence is
# od -c .
xxxxxxxx ? > 307 p \0 \0 \0 \0 \0...
xxxxxxxx 3 5 f i l e 1 \0 \0...
.
.
.
# rm -i *
p: not found (the file name is not "p", but that is what
file1: the shell passed to the command. The garbage
file2: isn't printed)
.
.
.
filen:
Mark Longo AT&T ISL DENVER
(..!ihnp4!drutx!mrl)
<clever saying follows>
-----------------
Don't worry whether I'm right or wrong. Someone will
correct me either way!
More information about the Comp.unix
mailing list