davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/11/88)
Is there a better way to get rid of a file with a '/' in the name
than diddling the directory? "rm -i *" sure doesn't work here!
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -megwyn@brl-smoke.ARPA (Doug Gwyn ) (05/11/88)
In article <10777@steinmetz.ge.com> davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: >Is there a better way to get rid of a file with a '/' in the name >than diddling the directory? "rm -i *" sure doesn't work here! Odds are excellent that what appears to be / really has the hex value AF, i.e. the high bit is set. Apparently your shell is not 8-bit capable. Why would you think that "rm -i *" should work? Try "rm -ri .".
trt@rti.UUCP (Thomas Truscott) (05/11/88)
> Is there a better way to get rid of a file with a '/' in the name > than diddling the directory? "rm -i *" sure doesn't work here! Fixing filesystem corruption is a job for fsck, which could strip '/'s from directory entries. (It could also ensure that only '\0' characters follow the file name.) Unfortunately, I do not think any current fsck does that. This is fixed in 4.4 BSD, right? While you are waiting for your 4.4 BSD tapes to arrive I recommend you create a new directory, "mv" everything from the old to the new directory (except the badly-named file which will not move), and then unmount the filesystem and "clri" the old directory. If you are lucky fsck will put the formerly-badly-named file in lost+found. Tom Truscott
dg@lakart.UUCP (David Goodenough) (05/12/88)
From article <10777@steinmetz.ge.com>, by davidsen@steinmetz.ge.com (William E. Davidsen Jr): > Is there a better way to get rid of a file with a '/' in the name > than diddling the directory? "rm -i *" sure doesn't work here! Since this is a UNIX (tm) group I'm going to ask "how was a file with a '/' in it's name created?" I *_CANT_* do it here (BSD 4.3). And regarding it's removal, "rm -i *" will fail because * expands, and rm gets a name with a '/' in it, so unlink(2) starts looking for sub- directories. Even an "rm -ir ." may well fail, because the string that gets handed to unlink(2) (and presumably namei()) still has a '/' in it. (If this is a SYS V problem then some of what I have said may be wrong - I have never worked with SYS V - just BSD 4.X) -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!adelie!cfisun!lakart!dg +-+-+ | +---+
rbj@icst-cmr.arpa (Root Boy Jim) (05/17/88)
From: David Goodenough <dg@lakart.uucp> Since this is a UNIX (tm) group I'm going to ask "how was a file with a '/' in it's name created?" I *_CANT_* do it here (BSD 4.3). By a stray neutrino zapping the directory entry. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement
barmar@think.COM (Barry Margolin) (05/18/88)
In article <14418@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: > From: David Goodenough <dg@lakart.uucp> > Since this is a UNIX (tm) group I'm going to ask "how was a file with a '/' > in it's name created?" I *_CANT_* do it here (BSD 4.3). > >By a stray neutrino zapping the directory entry. If you use memory and disk without ECC, you deserve to lose this way. (Unfortunately, I think most personal computers don't have any memory ECC -- users of A/UX should flame heavily at Apple about this.) Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/19/88)
In article <20800@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes: | In article <14418@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: | > From: David Goodenough <dg@lakart.uucp> | > Since this is a UNIX (tm) group I'm going to ask "how was a file with a '/' | > in it's name created?" I *_CANT_* do it here (BSD 4.3). | > | >By a stray neutrino zapping the directory entry. Since I posted the original question (and have lots of comments but no answers) I will note that someone with root access was trying to open the dir file and treat it as a database, building an index file by <lots of things>. They blewitt. | If you use memory and disk without ECC, you deserve to lose this way. | (Unfortunately, I think most personal computers don't have any memory | ECC -- users of A/UX should flame heavily at Apple about this.) Given the low frequency of errors, error detection via parity seems to work adequately. If I remember correctly, an ECC code for a byte takes 4 bits extra (!), and for four bytes as a unit 6. I don't know how aux does it, but the PCs have one parity per byte. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
kimcm@ambush.UUCP (Kim Chr. Madsen) (05/19/88)
> Since this is a UNIX (tm) group I'm going to ask "how was a file > with a '/' in it's name created?" I *_CANT_* do it here (BSD 4.3). Well, last time it happened here it was due to a user's foot, by which he accidently turned off the power to the computer, while unbatching news! What happened was that one could read news with ls(1), the indirect/direct diskblocks was pretty jammed up. Accidently the phrase "what s/he said " appeared as a filename and this really made a pain in the neck. Trying to clean up the system after this wasn't easy, although a good job was performed by fsck(1M), but the file with a '/' in its name caused fsck to go into an infinite loop. Trying to remove the file in a conventional way failed miserable since the filename violates one of the most sacred laws in the UNIX world "thou shall not put slashes in thy filenames". What we actually did was to backup as much of the /usr/spool disk, reformatted, and created a new filesystem on it and restored the saved data. I sure do hope it will take a very long time before such things happen again, it took 3+ hours and 1+ litre of perspiration to fix. Regards, Kim Chr. Madsen, AmbraSoft A/S, Rojelskaer 15, DK-2840 Holte (Denmark) UUCP: kimcm@ambush.dk, PHONE: +45 2424 111, FAX: +45 2423 090 You shouldn't say it's no good. You should say you do not like it; and then, you know, you're perfectly safe. -- James Abbott McNeill Whistler --
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/19/88)
In article <10894@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > Since I posted the original question (and have lots of comments but no >answers) I will note that someone with root access was trying to open >the dir file and treat it as a database, building an index file by <lots >of things>. They blewitt. It is not supposed to be possible for even UID 0 to write on a directory, EXCEPT via access to the "raw device". If the apparent '/' has the high bit set, then you already received an answer. If not, then you'll have to ALSO access the "raw device" -- basically you need to "zap" the entry using fsdb or equivalent, then get fsck to fix up the filesystem.
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/19/88)
There is a program from the net called rmgarbage which does renaming
of bad filenames. I am going to check to see if it knows / as bad, but
it fixes control and 8th bit characters.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -merbj@icst-cmr.arpa (Root Boy Jim) (05/20/88)
In article <14418@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: > From: David Goodenough <dg@lakart.uucp> > Since this is a UNIX group I'm going to ask "how was a file with a '/' > in it's name created?" I *_CANT_* do it here (BSD 4.3). > >By a stray neutrino zapping the directory entry. If you use memory and disk without ECC, you deserve to lose this way. (Unfortunately, I think most personal computers don't have any memory ECC -- users of A/UX should flame heavily at Apple about this.) What makes you think ECC works *ALL THE TIME*? Just mostly. Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement My name is in /usr/dict/words. Is yours?
rbj@icst-cmr.arpa (Root Boy Jim) (05/20/88)
Even root cannot write to a directory.
mouse@mcgill-vision.UUCP (der Mouse) (05/30/88)
In article <763@ambush.UUCP>, kimcm@ambush.UUCP (Kim Chr. Madsen) writes: >> Since this is a UNIX (tm) group I'm going to ask "how was a file >> with a '/' in it's name created?" I *_CANT_* do it here (BSD 4.3). > Well, last time it happened here it was due to a user's foot, by > which he accidently turned off the power to the computer, while > unbatching news! [Thus a filename "what s/he said " appeared.] > Trying to clean up the system after this wasn't easy, although a good > job was performed by fsck(1M), but the file with a '/' in its name > caused fsck to go into an infinite loop. I hope you reported this as a bug. *Nothing* in the filesystem should *ever* cause fsck to fail (hang, crash, go nuts...). > What we actually did was to backup as much of the /usr/spool disk, > reformatted, and created a new filesystem on it and restored [...]. What I'd recommend is: - create a parallel directory, call it ../salvage # mkdir ../salvage - move all the "good" files/subdirectories into ../salvage # mv * ../salvage (error message about "what s/he said " goes here) (be careful - if you have any dot files in this directory, move them too) (at this point there should be nothing but the bad entry left in this directory) - shuffle names # cd .. # mv old-name trashed # mv salvage old-name ("old-name" is of course the name of the directory with the bogus entry) - get the inumber of the directory with the trashed entry # ls -id trashed 23040 trashed (your number will probably differ) - unmount the filesystem # cd / # umount /dev/ra0j (of course, substitute the real device name) - nuke the directory with the bogus entry # clri /dev/ra0j 23040 (change device name and inumber as appropriate) - fix up the filesystem # fsck /dev/ra0j (normal fsck happenings....) remount, and away you go. There now, that wasn't so bad, was it? An interesting little problem. I shall have to experiment here (4.3BSD) and see whether our fsck is as faulty, and whether the above sequence works as it ought to get rid of the entry. (Creating such is fairly easy if you have access to the raw device.) der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu