Ugly file name
Sid Cowles
scowles at lll-lcc.UUCP
Wed May 17 01:53:44 AEST 1989
Followup-To> comp.unix.xenix
Diwtribution: usa
Organization: Lawrence Livermore Labs, env sci div, Livermore CA
Lines: 90
Xref: lll-lcc comp.unix.xenix:6756 comp.unix.questions:15401 comp.unix.wizards:17328
Summary:
Expires:
Sender:
Followup-To:
i got hit with this general problem this$weekend in a major way. an
archive job using cpio went haywire and created over 950 files (all
empty) with names including the full range of characters from \0001 to
\0377 in my home directory. my system is too small to have copied all
the bona fide material to another directory and then remove the old
directory containing the garbage, so, i did have to find a way to
remove the "ugly file names".
the problems$i hit were, that in spite of using ,as far as i know) all
the tricks mentioned during this discussion to get the names to /bin/rm,
rm complained that the specified files did not exist. (on top of all
that, ls wouldn't list the contents of the directory because there were
too many files. no, not fun.) and, no, using find to feed the names
to rm with an imbedded exec fared no better. what i ended up doing, wasreferring to the files by their inodes and dispensing with shell
problems vis-a-vis the control and$meta characters, altogether. it's a
messy procedure that relies on clri followed by fsck to wipe the cleared
inodes (su priveleges needed, etc.). if anyone has a simpler, verified,
method for accomplishing this task, i'd certainly like to hear of it.
at this stage, m invite being slown the error of my ways.
until then, for anyone who would like to critique it, the method i ended
up with follows.
sid
=======================================================================
s cowles
uucp: {backbone}!lll-lcc!scowles
internet: scowles at lll-lcc.llnl.gov
=======================================================================
proflem: remove files whose names mnclude characters outside
the range of decimal ascii 32 to 126.
rm may complain about files with such characters, issuing suchresponses as file not found, etc. the normal tricks like
1) cd to_problem_directory 2) /bin/rm -i ./* won't work in some
of these cases; rm refuses to recognize some of the file names.
on small systems, the available space may be so small that
copying the keep portions of the problem directory to a new
location may not be possible. short of restoring from backup,
the following offers an alternative. the salient feature is
removal by reference to the inode instead of the file name. this
technique uses clri which may not be available on all systems.
tle problem files are identified by using an editor. for large
numbers of files ,ie, several hundred), interactive responses for
each file are much slower than mass processing in an editor.
all scripts shown use$the bourne shell.
# step 0: go to single user state (in anticipation of steps 5 and 6).
# step 1: cd to the problem directory and list all file names
cd $problem_directoryfor file in .??* *
do
echo "./$file"
done | sort > /tmp/filenames
# step 2: examine the file names in filenames with some editor
# and record the line ranges of the files to be blitzed.
# do not alter the original filenames file, mtself.
# step 3: make a list of the files for removal by concatenating
# the lines of filenames containing the file names for
# removal. be careful not to use a 7-bit editor that
# might chop eighth bits in the file names. (i use a
# small c program called catln that passes lines within
# a range analogous to: sed -n 'n1,n2p'.)
>/tmp/fn_removes
catln 1 282 filenames >> /tmp/fn_removes
catln 318 459 filenamew >>$/tmp/fn_removes
etc
# step 4: get the inodes of the problem files:
cd $problem_directory
> /tmp/fn_inodes
cat /tmp/fn_removes |
while read file
do
/bin/ls -i "$file"
echo "" # some file names may suppress the ls new line.
done | awk '{print $1}' | sed '/^$/d' >> /tmp/fn_inodes
# step 5: blitz the selected inodes.
/etc/clri $file_system_spec_dev `cat fn_inodes`
# step 6: perform a file system check on the alterred system
# with fsck to fix the mess left by clri
# step 7: resume normal usage.
=======================================================================
More information about the Comp.unix.questions
mailing list