bill@TWG.UUCP (Bill Irwin) (06/01/90)
Here is one that has got me beat, frustrated and down right angry. I have some files in a directory that I can't remove. When I "ls" the directory the output puts my terminal into graphics mode. There are several of these culprits and in each one you can see a letter or two in the file name. When I do "rm -i *k*" I get told "%%%%%k#@!0=-+ not found". I even got desperate and did "rm -r" on the directory, but it wouldn't remove it because it wasn't empty...because it couldn't find some of the files to remove, etc etc. I feel like editing the directory file and changing the names of these files from control characters to ascii so I can remove them, but you can't edit a directory file (please correct me if I'm wrong on this). For those of you who feel up to tackling this one, I can included the output of two "ls" runs. The first uses the "-b" flag to print non-graphic characters in octal. The second used the "-q" flag for question mark substitution. -b output: \002K\007\027k\037\744\035\650\002j'\005\004 \004F\010k# \007A%\027k\036\746\035\700\002\013\004\610- \007A'z*\025\004j\010k#\610#\630 \015\670 \010\002K\006\027A?\007UFz \024@\027\607\001'\635\0019\6448\615\001 A7\010$\015\670 \010\002K\006\027A? A7j+\005\004b\030aP#\640\001\030 C\030\007k\015\720\016\766\002\027k\035\700\036 k#(#\610\010\007A'z(\025\004\ \646\035\652\001j)\005\004e\030k"\700# -q output ?K??k?????j'?? ?F?k# ?A%?k????????- ?A'z*??j?k#?#? ?? ??K??A??UFz ?@???'??9?8?? A7?$?? ??K??A? A7j+??b?aP#??? C??k??????k??? ????j)??e?k"?# I am running SCO XENIX V/386 2.3.2 on a 386/33Mz system. To the one who scores on this I will be forever indebted. Reformatting the disk does seem a little drastic. -- Bill Irwin TWG The Westrheim Group ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ uunet!van-bc!twg!bill (604)431-9600 (voice) (604)431-4629 (fax) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ronald@atcmp.nl (Ronald Pikkert) (06/03/90)
From article <156@TWG.UUCP>, by bill@TWG.UUCP (Bill Irwin): > Here is one that has got me beat, frustrated and down right angry. I > have some files in a directory that I can't remove. Your shell probably strips the high order bit which causes rm to be unable to delete these files. You can remove them using a c-program. I wrote a shell script that creates a c-program that does the job: ------------------- cut here ------------------ echo "main() {" ls -b | sed 's/\(\\\)\([^0]\)/\10\2/g s/\\$/\\\\/ s/"/\\"/g s/^/unlink(\"/ s/$/");/ ' echo "}" ------------------- cut here ------------------ Run this script in the directory and it will generate a program dl.c Compile the program (cc dl.c -o dl). The run ./dl and there will be no need to reformat your anymore disk :-) - Ronald Pikkert E-mail: ronald@atcmp.nl @ AT Computing b.v. Tel: 080 - 566880 Toernooiveld 6525 ED Nijmegen
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/04/90)
In article <610@atcmpe.atcmp.nl> ronald@atcmp.nl (Ronald Pikkert) writes: >Your shell probably strips the high order bit which causes rm to be unable >to delete these files. But that doesn't explain why "rm -r" would fail to remove them.
thorinn@skinfaxe.diku.dk (Lars Henrik Mathiesen) (06/05/90)
gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >ronald@atcmp.nl (Ronald Pikkert) writes: >>bill@TWG.UUCP (Bill Irwin) writes: >>>[He has problems with garbage characters in file names on SCO XENIX] >>Your shell probably strips the high order bit which causes rm to be unable >>to delete these files. >But that doesn't explain why "rm -r" would fail to remove them. In 4.? BSD, the kernel will not accept path names with the high order bit set in some character. I have never seen a BSD filesystem spontaneously generate link names with high bits set, but a disk failure could cause this. However, I know of two similar cases where "rm -r" falied to work. The first was on a SYSV system, where a disk problem had caused some '/' characters to appear in a directory. clri/fsck to the rescue. Or was it adb on the raw disk? The other case happened to me a few weeks ago. We run a number of MORE/bsd systems (4.3-tahoe with NFS, more or less). We also run a number of Sun systems; one of them holds some users' home directories. I got a problem report with the same gist: "ls -l *" reported (i.a.) " not found". Somehow a file had been created with a name with only high-bit-set characters on the Sun server (which allowed it). Nothing could be one with it from the MORE/bsd machines. One of these days I'm going to remove the check for the high bit in remote filenames. -- Lars Mathiesen, DIKU, U of Copenhagen, Denmark [uunet!]mcsun!diku!thorinn Institute of Datalogy -- we're scientists, not engineers. thorinn@diku.dk
daveh@marob.masa.com (Dave Hammond) (06/05/90)
In article <13043@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >In article <610@atcmpe.atcmp.nl> ronald@atcmp.nl (Ronald Pikkert) writes: >>Your shell probably strips the high order bit which causes rm to be unable >>to delete these files. > >But that doesn't explain why "rm -r" would fail to remove them. Is it possible that there is really no file with this weird name, but the directory itself got bashed so that a directory slot which should have zeros in the inode field actually contains garbage? Wouldn't this make ls think there was a file with a garbage name, but unlink would fail causing rm to claim the file was not found? -- Dave Hammond daveh@marob.masa.com uunet!masa.com!marob!daveh
bill@twg.UUCP (Bill Irwin) (06/06/90)
In article <266B2780.3A84@marob.masa.com> daveh@marob.masa.com (Dave Hammond) writes: >Is it possible that there is really no file with this weird name, but >the directory itself got bashed so that a directory slot which should >have zeros in the inode field actually contains garbage? Wouldn't this >make ls think there was a file with a garbage name, but unlink would >fail causing rm to claim the file was not found? You pose a very intrigueing question. I would like to persue it. My question is: how do I verify that zero inodes are garbage, and if so, how do I fix it? -- Bill Irwin - TWG The Westrheim Group - Vancouver, BC, Canada ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ uunet!van-bc!twg!bill (604) 431-9600 (voice) | UNIX Systems Bill.Irwin@twg.UUCP (604) 431-4629 (fax) | Integration