ZAT011%DJUKFA11.BITNET@cunyvm.cuny.edu (Thomas Heil) (11/15/88)
Hello, folks! I got a little problem with a "ghost file". It appears when I list the contents of a directory, but it can't be accessed in any way - every program tells me it doesn't exist. It can't even be removed. But the directory (only containing that file) cannot be removed because it's not empty. And I can even create another file with the same name which then appears twice. Seems to me like a file system corruption due to a missing shutdown before the plug was pulled. Any help? /Thomas +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Thomas Heil | BITNET: ZAT011@DJUKFA11.BITNET | | Kernforschungsanlage Juelich | | | Zentralabteilung Allgemeine | | | Technologie | | | D-5170 Juelich | Phone: +49 2461 61-6328 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
debra@alice.UUCP (Paul De Bra) (11/16/88)
In article <17529@adm.BRL.MIL> ZAT011%DJUKFA11.BITNET@cunyvm.cuny.edu (Thomas Heil) writes: >Hello, folks! > >I got a little problem with a "ghost file". It appears when I list the >contents of a directory, but it can't be accessed in any way - every >program tells me it doesn't exist. It can't even be removed. But the >directory (only containing that file) cannot be removed because it's not >empty. And I can even create another file with the same name which then >appears twice... > I would suspect that the name of the ghost file contains a non-printable character, which doesn't show up when you try ls. A way to find out is to make an octal dump of the directory. Another way of trying to delete the file is to try to generate the name: if it appears as "ghost" in the directory you could try rm *g*h*o*s*t* I assume you ran fsck already, so the file system probably is not corrupt. Normally you will never be able to create a second identical entry in the directory. Hope this helps. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
predict@charon.unm.edu (Andrew R. Large) (11/16/88)
In article <17529@adm.BRL.MIL> ZAT011%DJUKFA11.BITNET@cunyvm.cuny.edu (Thomas Heil) writes: >I got a little problem with a "ghost file". It appears when I list the >contents of a directory, but it can't be accessed in any way - every >program tells me it doesn't exist. It can't even be removed. But the Most likely, the file name has some control characters in it that are not displayed by {ls,your terminal}. Try doing a % vi * and see what vi calls it or % ls > file ; vi file to see what the actual file name is. You can probably verify its existence by doing an od -c on the directory and checking the inode number. In most cases, an rm * should take care of it, or an rm -rf on the dir. If not, try an fsck on the partition and see if the file goes away. -- Andy -- -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- * Andrew R. Large * ** (work) 505/255-8611 ------| Univ of New Mexico EECE Department ** *** (home) 505/888-4010 |---> Management Sciences, Inc. [MSI] *** **** _Babooshka!_ **** *** Usenet: {convex,gatech,ucbvax,csu-cs,anl-mcs}!unmvax!charon!predict *** ** Internet: predict@charon.UNM.EDU ** * If I am quoted, my employers will deny my existence. * -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
logan@vsedev.VSE.COM (James Logan III) (11/16/88)
In article <17529@adm.BRL.MIL> ZAT011%DJUKFA11.BITNET@cunyvm.cuny.edu (Thomas Heil) writes: >I got a little problem with a "ghost file". It appears when I list the >contents of a directory, but it can't be accessed in any way Have you looked to see if the filename contains control characters? The name might really be "filee^Hname" which would look like "filename" in a directory listing. To check for this, type ls -bl some_directory and see if it prints an octal code in the file name. (BSD systems may have a different option letter for this.) -Jim -- Jim Logan logan@vsedev.vse.com (703) 892-0002 uucp: ..!uunet!vsedev!logan inet: logan%vsedev.vse.com@uunet.uu.net
jpr@dasys1.UUCP (Jean-Pierre Radley) (11/17/88)
In article <8430@alice.UUCP> debra@alice.UUCP () writes: >In article <17529@adm.BRL.MIL> ZAT011%DJUKFA11.BITNET@cunyvm.cuny.edu (Thomas Heil) writes: >>I got a little problem with a "ghost file". It appears when I list the >>contents of a directory, but it can't be accessed in any way - every >>program tells me it doesn't exist. It can't even be removed. But the >>directory (only containing that file) cannot be removed because it's not >>empty. And I can even create another file with the same name which then >>appears twice... >I would suspect that the name of the ghost file contains a non-printable >character, which doesn't show up when you try ls. A way to find out is >to make an octal dump of the directory. >Another way of trying to delete the file is to try to generate the name: >if it appears as "ghost" in the directory you could try >rm *g*h*o*s*t* More than likely, the "ghost file" does contain "bad" characters. "Bad" means that you probably can't enter these characters from the keyboard, and even if you've made an octal dump to see _all_ of the file name, you won't be able to type it as an argument to 'rm'. If the bad name starts with "-", 'rm' thinks it's an option, not a file name. If the bad name has backspaces or non-printable characters, then it may _appear_ on your terminal to have the "same" name as a another file. It may be so screwed up that the "*" metacharacter won't expand into such a bad name (and if the name starts with ".", then the "*" also won't help). How to stomp on such insects: Go to the directory in question and type "ls -i". Make a note of the inode number, say NNNNN, of the offender. Then: find . -inum NNNNN -exec rm {} \; -- Jean-Pierre Radley Honi soit jpr@dasys1.UUCP New York, New York qui mal ...!hombre!jpradley!jpr CIS: 76120,1341 y pense ...!hombre!trigere!jpr
mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield (Mike)) (11/17/88)
In article <17529@adm.BRL.MIL> ZAT011%DJUKFA11.BITNET@cunyvm.cuny.edu (Thomas Heil) writes: >I got a little problem with a "ghost file". It appears when I list the >contents of a directory, but it can't be accessed in any way - every >program tells me it doesn't exist. It can't even be removed. But the >directory (only containing that file) cannot be removed because it's not >empty. And I can even create another file with the same name which then >appears twice. Seems to me like a file system corruption due to a >missing shutdown before the plug was pulled. Yeah. It isn't a ghost file, it's a file with a non-printing character in the name (like a space or a tab or a bell ....). When you create a new file of the "same" name, it doesn't have the embedded boggy so you really have two files with two different names that simply appear alike. If you have everything out of the directory, the easiest thing to do is "rm -r <directory>" from the parent directory. Thougher, but doable, is to use some diagnostic tools to do direct editing on the "directory" entry and change the name to something real. Tricks like that should only be attempted out of shear despiration and only if you are willing to risk the potential catastrophic damage any simple mistake can cause (doesn't sound like you're that far yet). Michael H. Warfield (The Mad Wizard) | gatech.edu!galbp!wittsend!mhw (404) 270-2123 / 270-2098 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it!
rwhite@nusdhub.UUCP (Robert C. White Jr.) (11/17/88)
in article <8430@alice.UUCP>, debra@alice.UUCP (Paul De Bra) says: <> <> In article <17529@adm.BRL.MIL> ZAT011%DJUKFA11.BITNET@cunyvm.cuny.edu (Thomas Heil) writes: <>>I got a little problem with a "ghost file". It appears when I list the <>>contents of a directory, but it can't be accessed in any way - every <>>program tells me it doesn't exist. It can't even be removed. But the <>>directory (only containing that file) cannot be removed because it's not <>>empty. And I can even create another file with the same name which then <>>appears twice... <> I would suspect that the name of the ghost file contains a non-printable <> character, which doesn't show up when you try ls. A way to find out is <> to make an octal dump of the directory. <> Another way of trying to delete the file is to try to generate the name: <> if it appears as "ghost" in the directory you could try <> rm *g*h*o*s*t* There is no deed to get baroque over these files. use the "-b" option to ls so that it will display non-printing characters as octal strings. If nothing will locate tthe file, move everything out of the directory that you want to keep, and then "rm -rf directory" instead of rmdir. This is not so bad as you might think. I have users adding files that contain arrow key codes, and line hits all the time. gopher baroque! Rob.
devusr@nswc-oas.arpa (11/17/88)
(Thomas Heil) writes: >Hello, folks! > >I got a little problem with a "ghost file". It appears when I list the >contents of a directory, but it can't be accessed in any way - every >program tells me it doesn't exist. It can't even be removed. (Paul De Bra <debra@alice.uucp>) responds: >Another way of trying to delete the file is to try to generate the name: >if it appears as "ghost" in the directory you could try >rm *g*h*o*s*t* Yet another approach would be to use `ls -i' on the directory containing the ghost file. Then, use a `find' command to remove the file: find . -inum XXX -exec rm {} \; where XXX is the inode number reported by ls. /dave
wu@spot.Colorado.EDU (WU SHI-KUEI) (11/18/88)
In article <6512@galbp.LBP.HARRIS.COM> mhw@wittsend.UUCP (Michael H. Warfield (Mike)) writes: >In article <17529@adm.BRL.MIL> ZAT011%DJUKFA11.BITNET@cunyvm.cuny.edu (Thomas Heil) writes: [much stuff deleted] > Yeah. It isn't a ghost file, it's a file with a non-printing character >in the name (like a space or a tab or a bell ....). This works on AT&T 3B2's and Ultrix: Find the inumber of the file with 'ls -i'. Then do find . -inum inumber -exec rm {} \; or find . -inum inumber -exec mv {} foo \; or whatever your little heart desires. The '-inum' expression was documented in the 7th Edition manuals and has been available in all AT&T releases ever since - SYS III, IV and V, even though not documented. It was a pleasant surprise to find that Ultrix at least did something right! Just a guest here. In reality Carl Brandauer {uunet!stcvax}!nbires!bdaemon!carl
sysop@pinn.UUCP (Andy Johnson) (11/18/88)
In article <8430@alice.UUCP>, debra@alice.UUCP (Paul De Bra) writes: > In article <17529@adm.BRL.MIL> ZAT011%DJUKFA11.BITNET@cunyvm.cuny.edu (Thomas Heil) writes: > I would suspect that the name of the ghost file contains a non-printable > character, which doesn't show up when you try ls. A way to find out is > to make an octal dump of the directory. You can also type in rm -i * That will interactively ask you to delete each file including the ghost file. Andy
mjh@uunet.uu.net (Mark J. Hewitt) (11/18/88)
You probably have a non-printing character in the filename. You don't
say what UNIX you run, but you should look at your `ls(1)' manual page
to determine how you see all the characters in the name. For System V
it would be ls -lab to show such characters in octal `\nnn' form.
Mark J. Hewitt
usenet: ...!{mcvax,uunet}!ukc!kernel!mjh JANET: mjh@uk.co.kernel
voice: (+44) 532 444566 other: mjh@kernel.co.uk
fax: (+44) 532 425456 old style: mjh%uk.co.kernel@uk.ac.ukc
paper: Kernel Technology Ltd, Development Centre, 46 The Calls, Leeds,
LS2 7EY, West Yorkshire, UKasmodeus@tree.UUCP (Jonathan Ballard) (11/20/88)
In article <17566@adm.BRL.MIL>, devusr@nswc-oas.arpa writes: > (Thomas Heil) writes: > >Hello, folks! > > > >I got a little problem with a "ghost file". It appears when I list the > >contents of a directory, but it can't be accessed in any way - every > >program tells me it doesn't exist. It can't even be removed. > > (Paul De Bra <debra@alice.uucp>) responds: [ stuff deleted] > >rm *g*h*o*s*t* [stuff deleted] > find . -inum XXX -exec rm {} \; > where XXX is the inode number reported by ls. > > /dave And another way, which will find out the full name it is uder is to do a od -cb . It will run threw and show the ascii and binary code of the directory. If yours is set up like my the first two chaaracters are the inode number and the rest (asumming 14 more) on that line is the name. You should see there if there is any extra characters that ls would not print out. Then you could use rm to remove it while you add that non-graphic character. -- _ | | \ UUCP e-mail: ..!{csusac,pacbell}!sactoh0!tree!asmodeus | |-< ..!csusac!tree!asmodeus |__|on |_/allard
bill@bilver.UUCP (bill vermillion) (11/20/88)
In article <169@pinn.UUCP+ sysop@pinn.UUCP (Andy Johnson) writes: +In article <8430@alice.UUCP+, debra@alice.UUCP (Paul De Bra) writes: ++ In article <17529@adm.BRL.MIL+ ZAT011%DJUKFA11.BITNET@cunyvm.cuny.edu (Thomas Heil) writes: ++ I would suspect that the name of the ghost file contains a non-printable ++ character, which doesn't show up when you try ls. A way to find out is ++ to make an octal dump of the directory. + +You can also type in rm -i * That will interactively ask you to delete +each file including the ghost file. + +Andy I tried that (rm -i *) with a ghost file and it did NOT work. Dumped the directory and found that the file name had a printable letter, 0x08, and two more letters. The 0x08 (backspace) effectively masked the first letter. rm -i * would prompt with the name, and then give a file not found error. The only way to get rid of one of those is to kill with the find . -inum etc, etc routine posted earlier. I also replied earlier, and had a great mistake in my reply. I killed it soon after, but it did get out, so I apologize for typing off the top of my head earlier (if any of you saw that reply). -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!bill : bill@bilver.UUCP
mchinni@ardec.arpa (Michael J. Chinni, SMCAR-CCS-E) (11/23/88)
bill vermillion <bill@bilver.uucp> > In article <169@pinn.UUCP+ sysop@pinn.UUCP (Andy Johnson) writes: > +In article <8430@alice.UUCP+, debra@alice.UUCP (Paul De Bra) writes: > ++ In article <17529@adm.BRL.MIL+ ZAT011%DJUKFA11.BITNET@cunyvm.cuny.edu (Thomas Heil) writes: > ++ I would suspect that the name of the ghost file contains a non-printable > ++ character, which doesn't show up when you try ls. A way to find out is > ++ to make an octal dump of the directory. > + > +You can also type in rm -i * That will interactively ask you to delete > +each file including the ghost file. > + > +Andy > > I tried that (rm -i *) with a ghost file and it did NOT work. Dumped the > directory and found that the file name had a printable letter, 0x08, and two > more letters. The 0x08 (backspace) effectively masked the first letter. > rm -i * would prompt with the name, and then give a file not found error. > The only way to get rid of one of those is to kill with the > find . -inum etc, etc routine posted earlier. When I tried the following: 1) set "stty erase ^X" 2) echo hi > a^Hqw 3) set "stty erase ^H" 4) rm -i * "rm" doesn't complain. System is ULTRIX 1.2. rm is /bin/rm (std. rm). When doing a "ls" I get the file showing as "a?qw". ()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()() X X / \ / \ | | | | Michael J. Chinni || | | || |||| | | |||| US Army Armament Research, Development, /\ |||||| | | |||||| /\ and Engineering Center || |||||||| | | |||||||| || |||||+---+|| | | ||+---+||||| Picatinny Arsenal, New Jersey ||||||\./||| | | |||\./|||||| ||||||.X.||| | | |||.X.|||||| ||||||/.\||| | | |||/.\|||||| ARPA: mchinni@ardec.arpa ||---+---+-| | | |-+---+---|| UUCP: ...!uunet!ardec.arpa!mchinni || ||||||| | | | | ||||||| || AT&T: 201-724-4140 ++ +-+ +-+ ++ ()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()() #include <std.disclaimer>
guy@auspex.UUCP (Guy Harris) (11/23/88)
>I tried that (rm -i *) with a ghost file and it did NOT work. Dumped the >directory and found that the file name had a printable letter, 0x08, and two >more letters. The 0x08 (backspace) effectively masked the first letter. >rm -i * would prompt with the name, and then give a file not found error. The only way I can believe that story is true is if you have an excessively helpful shell, or if some of the "printable" letters really had their 8th bit set and you had an insufficiently helpful shell. If the file's name is "f<BS>duck", where "<BS>" refers to the "backspace" character, doing "rm -i *" under a sane Bourne, Korn, or C shell would cause "rm" to print something like rm: remove duck? (the word "remove" may be absent, depending on your UNIX version), and if you say "y" it will quite cheerfully remove the file whose name it printed - that name is "f<BS>duck", which happens to print as "duck" on most terminals these days. No shell I know of will remove the printable letter and backspace, nor will any UNIX kernel I know of. If the 8th bit is set, the shell might strip the 8th bit off before passing it to "rm", in which case "rm" will not have the proper name of the file and will not be able to remove it. Versions of the Bourne shell prior to the System V Release 3 version, and versions of the C shell from Berkeley, will strip the 8th bit (as they use that bit internally for quoting). The System V Release 3 Bourne shell (present in SunOS 4.0 and later) will not strip the 8th bit.
drl@vuse.vanderbilt.edu (David R. Linn) (11/23/88)
Sorry to drag out this topic but this bounced and makes what I consider a good point. ----- Begin Included Message ----- In UNIX-WIZARDS Digest V6#021, Jean-Pierre Radley <jpr@dasys1.uucp> writes: >It may be so screwed up that the "*" metacharacter won't expand into such >a bad name (and if the name starts with ".", then the "*" also won't >help). In fact, I encountered just such a situation recently, where a program mistakenly created files with a "\213\316#\317" (C-escapes apply) prefix. In this case, "rm -i *" will *NOT* work. The Bourne shell uses the 8th bit of characters for special purposes and so botches the expansion of wildcards that produce filenames that already have the 8th bit set. For this reason, you want to avoid wildcards. In my case, I was able to go to the affected directory and type: $ rm -ri . since rm knows how to read directories without any assistance from a shell. This wildcard problem should be fixed with the "internationalized" shells such as ksh-i. David David Linn, System Manager/Postmaster |INET: Vanderbilt University School of Engineering| drl@vuse.vanderbilt.edu Post Office Box 1824, Station B |Phone: Nashville, TN, USA 37235 | [+1] 615-343-6164 ----- End Included Message -----
woods@gpu.utcs.toronto.edu (Greg Woods) (11/23/88)
In article <303@bilver.UUCP> bill@bilver.UUCP (bill vermillion) writes: > In article <169@pinn.UUCP+ sysop@pinn.UUCP (Andy Johnson) writes: > +In article <8430@alice.UUCP+, debra@alice.UUCP (Paul De Bra) writes: > ++ In article <17529@adm.BRL.MIL+ ZAT011%DJUKFA11.BITNET@cunyvm.cuny.edu (Thomas Heil) writes: > ++ I would suspect that the name of the ghost file contains a non-printable > + > +You can also type in rm -i * That will interactively ask you to delete > +each file including the ghost file. > > I tried that (rm -i *) with a ghost file and it did NOT work. Dumped the > directory and found that the file name had a printable letter, 0x08, and two > more letters. The 0x08 (backspace) effectively masked the first letter. > rm -i * would prompt with the name, and then give a file not found error. > The only way to get rid of one of those is to kill with the > find . -inum etc, etc routine posted earlier. > This has been bantered about quite a bit, but I must say a few words. Either your rm is broken, or your shell has a bug. Since rm did prompt with the printed representation of the filename, either your shell flubbed the filename expansion (and generated a command line with the printed representation of the filename instead of the actuall filename. On the other hand, your rm might have goofed somewhere between reading the command line, and calling unlink(). I would tend to think the problem is in your shell. Do you have more than one shell on your system? Did you try them all? Iff your rm is working correctly, a much simpler solution to the problem is to try 'rm -ri .'. This way any non-printable characters do not have to be passed through the command line, and even characters with their 8'th bit set will not get clobbered. (Many, if not all older shells will strip the 8'th bit.) Though I haven't run across one, it is possible that some versions of rm will also strip 8'th bits. If rm, or all the shells are broken, you will have to resort to eliminating the file by its inode number (or by calling unlink() from a C programme). -- Greg Woods. {utgpu,lsuc!gate,ontmoh}!woods, woods@{gpu.utcs.Toronto.EDU,utorgpu.BITNET} 1-416-443-1734 [h], 1-416-595-5425 [w] LOCATION: Toronto, Ontario, Canada
guy@auspex.UUCP (Guy Harris) (11/24/88)
>The Bourne shell uses the 8th bit of characters for special purposes
The Bourne shell, in releases prior to System V Release 3, uses the 8th
bit of characters for quoting purposes; the S5R3 Bourne shell, and later
releases, do not. SunOS 4.0, as well as systems that advertise
themselves as S5R3-based, have that version of the shell.
The C shell, as it comes from Berkeley, and versions of the Korn shell
prior to "ksh-i" also use the 8th bit for quoting purposes.hans@duttnph.UUCP (Hans Buurman) (11/24/88)
I made a file called "" the other day. That's "\0" in C, an empty string. (I was abusing elm). Although one could delete it using "rm -i *", there was no way to read the file. ls told me the file "?" was a plain file. Cat failed, more and file told me "" was a directory. I couldn't mv, ln or ln -s the file, etc. As I really wanted to read the file, I became super user and tried: link "" foo, and had to reboot the system because it was hanging. Angrily, I deleted the file. So now I am wondering: could I have read the file in any way ? This was on a Sun4 running SunOs 3.2. Hans Disclaimer: any opinions expressed above are my own. ----------------------------------------------------------------------------- Hans Buurman | hans@duttnph.UUCP Pattern Recognition Group | mcvax!dutrun!duttnph!hans Faculty of Applied Physics | tel. 31 - (0) 15 - 78 46 94 Delft University of Technology | the Netherlands | -----------------------------------------------------------------------------
allbery@ncoast.UUCP (Brandon S. Allbery) (11/25/88)
As quoted from <169@pinn.UUCP> by sysop@pinn.UUCP (Andy Johnson): +--------------- | In article <8430@alice.UUCP>, debra@alice.UUCP (Paul De Bra) writes: | > In article <17529@adm.BRL.MIL> ZAT011%DJUKFA11.BITNET@cunyvm.cuny.edu (Thomas Heil) writes: | > I would suspect that the name of the ghost file contains a non-printable | > character, which doesn't show up when you try ls. A way to find out is | > to make an octal dump of the directory. | | You can also type in rm -i * That will interactively ask you to delete | each file including the ghost file. +--------------- Not always. Line noise can create files with the 8th bit set in some characters, and older shells without 8th-bit support will botch the filenames, resulting in "rm: <filename> not found" or whatever. My Q&D solution is to "ls -b" into a file, edit the file to generate a C program with the filename hardcoded in it, and compile and run the program. Dired also works for this, although the version we have on ncoast chokes on directories that contain more than a few files. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
irf@kuling.UUCP (Bo Thide) (11/25/88)
In article <17625@adm.BRL.MIL> drl@vuse.vanderbilt.edu (David R. Linn) writes: [deleted text] >In UNIX-WIZARDS Digest V6#021, Jean-Pierre Radley <jpr@dasys1.uucp> >writes: >>It may be so screwed up that the "*" metacharacter won't expand into such >>a bad name (and if the name starts with ".", then the "*" also won't >>help). > >[deleted text] >mistakenly created files with a "\213\316#\317" (C-escapes apply) prefix. >In this case, "rm -i *" will *NOT* work. > >The Bourne shell uses the 8th bit of characters for special purposes >and so botches the expansion of wildcards that produce filenames that >already have the 8th bit set. For this reason, you want to avoid >[deleted text] In HP-UX with its Native Language Support (NLS), file names can have 7, 8 or 16 bit names. So "\213" is an allowed file name character, the 8th bit doesn't have a special meaning and "rm -i *" *WILL* work. This is an added bonus in addition to the other nice properties of a UNIX that is fully customizable in your own local language and "culture". The same should be true for any other UNIX supporting NLS (SysV.3?). -Bo ^ Bo Thide'-------------------------------------------------------------- | | Swedish Institute of Space Physics, S-755 91 Uppsala, Sweden |I| [In Swedish: Institutet f|r RymdFysik, Uppsalaavdelningen (IRFU)] |R| Phone: (+46) 18-403000. Telex: 76036 (IRFUPP S). Fax: (+46) 18-403100 /|F|\ INTERNET: bt@irfu.se UUCP: ...!enea!kuling!irfu!bt IP: 192.36.174.1 ~~U~~ -----------------------------------------------------------------sm5dfw
ccdn@levels.sait.edu.au (DAVID NEWALL) (11/25/88)
I had an off by one bug in a "high level" file access library, once. It's
effect was to append a single character (usually > 127) to the end of all
files created. Needless to say, I couldn't generate the filename from
within the shell, and so I couldn't delete it using rm.
But it turned out to be easy, to write a C program to delete the file. It
looked sort of like this:
main()
{
char name[] = "badfile?";
name[7] = (char) 255;
unlink(name);
}
Of course, I had to use "od" to find out the value of the `bad' character.
(Ls, by default, displays unprintable characters as "?").
--
David Newall Phone: +61 8 343 3160
Unix Systems Programmer Fax: +61 8 349 6939
Academic Computing Service E-mail: ccdn@levels.sait.oz.au
SA Institute of Technology Post: The Levels, South Australia, 5095guy@auspex.UUCP (Guy Harris) (11/26/88)
>I made a file called "" the other day. That's "\0" in C, an empty >string. No, you didn't. You did something else. A null pathname in most systems is either 1) a synonym for the current directory or 2) an illegal pathname. In SunOS, it's a synonym for the current directory.
hans@duttnph.UUCP (Hans Buurman) (11/26/88)
In article <512@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >>I made a file called "" the other day. That's "\0" in C, an empty >>string. > >No, you didn't. You did something else. A null pathname in most >systems is either > 1) a synonym for the current directory >or > 2) an illegal pathname. >In SunOS, it's a synonym for the current directory. This is interesting. What I did was, when asked under what name to save mail, enter return on an empty field, assuming that elm would use some default. It apparently did not. Who assumes "\0" is a synonym for "." ? The kernel, open(2),... ? The file I created was shown by ls -l as "-rw-r---- ?", but file(1) said it was a directory. It was in my home directory, and cd "" kept me there. As my home directory is rather full, I couldn't make anything out of an od of it. I don't remember the size of the file, and I cannot reproduce it. Any idea what happened ? Hans Disclaimer: any opinions expressed above are my own. ----------------------------------------------------------------------------- Hans Buurman | hans@duttnph.UUCP Pattern Recognition Group | mcvax!dutrun!duttnph!hans Faculty of Applied Physics | tel. 31 - (0) 15 - 78 46 94 Delft University of Technology |
guy@auspex.UUCP (Guy Harris) (11/27/88)
>Who assumes "\0" is a synonym for "." ? The kernel, open(2),... ? In SunOS (and systems that have adopted the SunOS VFS code), the routine "lookuppn". In 4.3BSD, the routine "namei". Both are in the kernel (as is "open()", which when calls ends up causing either "lookuppn" or "namei" to be called). >The file I created was shown by ls -l as "-rw-r---- ?", That doesn't look like "". That looks like a file with some non-printable character. "ls" in all UNIX implementations I know of treats file names as character strings, which means it treats '\0' as an end-of-string character, not a non-printable character; there's some real character there, not just a '\0'. >but file(1) said it was a directory. It was in my home directory, >and cd "" kept me there. Since "" is a synonym for "." in SunOS, 'cd ""' and 'cd .' do the same thing, namely keep you in the current directory. Similarly, 'file ""' will, just like 'file .', tell you it's a directory. It sounds like ELM "defaulted" to an uninitialized string which, in this particular case, contained a non-printable character followed by a '\0' (assuming that the "ls -l" in question did, in fact, show only one '?'; there could, presumably, have been blanks before and/or after it). You then assumed it actually created a file with a null name, and tried various operations on "". "rm -i *" probably succeeded, and gave the impression that it removed a file with a null name, because it actually tried removing a file with a name like "\001", and when it printed "\001" your terminal did nothing with the "\001". In other words, "rm"s message was something like rm: remove (\001)? which appeared as rm: remove ?
shadow@pawl6.pawl.rpi.edu (Deven T. Corzine) (11/27/88)
And, if all else fails, you should be able to get at it with:
rm -ri $PWD
along with everything else there. (happy prompting!)
Deven
/*********************************************************************\
* #include <std/disclaimer> *
* Deven T. Corzine USnail: 2346 15th St. *
* <<The Shadow>> Troy, NY 12180 *
* *
* Internet: BITNET: *
* shadow@pawl.rpi.edu USERFXB6@RPITSMTS.BITNET *
* shadow%pawl.rpi.edu@itsgw.rpi.edu *
* shadow@{uruguay,paraguay,brazil}.acm.rpi.edu *
\*********************************************************************/guy@auspex.UUCP (Guy Harris) (12/01/88)
> char name[] = "badfile?"; > name[7] = (char) 255; Or char name[] = "badfile\377"; which is slightly more convenient. I sincerely *hope* your compiler can cope with that (although it's not inconceivable that the compiler writer dropped the ball)....
dad@whuts.ATT.COM (DEGRAAF) (12/05/88)
>The file I created was shown by ls -l as "-rw-r---- ?", > In UNIX Sys V the command ls -b will reveal non-graphic characters that have become part of a filename by printing them in \ddd octal notation. This has saved me much aggravation in similar situations. I always use the -b option. Sometimes the find command can be used to remove or modify files that are otherwise recalcitrant. If you can manage to cause find to select the specific file, either using metacharacters in the name or other selectors, then -exec rm {} \; will do the trick. Dave De Graaf, pancho!dad