jwp@uwmacc.UUCP (jeffrey w percival) (05/29/85)
I've had a number of responses on how to remove the file whose name is
\t 360 200 035 002 \0
but no one has won yet. Most people recommended using unlink(2) like this:
main()
{
unlink("\t\360\200\035\002");
}
but this fails. One person even sent me a program that opened the directory,
searched for the entry representing the bad file, and passed that string,
unmolested in any way, to unlink:
fd = open(".", O_RDONLY);
... seek to proper entry ...
read(fd, &direct, sizeof(direct));
status = unlink(direct.d_name);
That failed too. Holy filename, Batman! What next?
--
Jeff Percival ...!uwvax!uwmacc!jwpjohn@x.UUCP (John Woods) (05/30/85)
> I've had a number of responses on how to remove the file whose name is > \t 360 200 035 002 \0 > but no one has won yet. Most people recommended using unlink(2) like this: > main() { > unlink("\t\360\200\035\002"); > } > but this fails. ... > That failed too. Holy filename, Batman! What next? > Jeff Percival ...!uwvax!uwmacc!jwp If that fails, you must have the "`feature'" turned on where 2.9 strips out "`illegal'" characters in file names. If so, you have one-and-a-half options: (.75) Go to your kernel sources, remove that feature, bulk-erase your distribution tape so it will never come back, recompile and reboot. Then do the unlink, unmolested by malfeatures. (1.5) Open the raw disk for writing with adb. When I have to patch disks by hand, I always print up extra copies of section 5 of the manual to have them arrayed in front of me... If you don't have sources, you're stuck with the second. Neither of them is enjoyable, but at least the first cures it forever. -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA "MU" said the Sacred Chao...
sml@luke.UUCP (Steven List) (06/02/85)
> > I've had a number of responses on how to remove the file whose name is > \t 360 200 035 002 \0 > but no one has won yet. Most people recommended using unlink(2) like this: > [...] > That failed too. Holy filename, Batman! What next? > > -- > Jeff Percival ...!uwvax!uwmacc!jwp Please forgive my ignorance: we're running SYSIII, and there's a nifty utility called fsdb. While I don't profess to proficiency in its use, I have used it in both similar and dissimlar instances. Does something like it exist in 2.9BSD? My worst, and most challenging, case involved an infinitely recursive directory. The directory looked something like this when printed with od -c .: 0000000 nnn nnn . \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 mmm mmm . . \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000040 nnn nnn s o m e f i l e \0 \0 \0 \0 \0 \0 0000060 nnn nnn s o m e f i l e 1 \0 \0 \0 \0 \0 0000100 nnn nnn s o m e f i l e 2 \0 \0 \0 \0 \0 where there were three files with the same inode number as the directory file itself. The ls command went bananas, especially with the -R option. The du command went off into lalaland. At first the only option appeared to be dumping and reloading the file system. I realized, however, that these same damn inodes would get dumped and reloaded. The rm command kept saying that the files were directories, and the rmdir (or rm -rf) command said the directory wasn't empty! Finally I tried fsdb. Worked like a charm!!! It does take a little figuring out, but it works wonders. If anyone has a reasonable tutorial for using fsdb out there, I would love to see it.
ken@turtlevax.UUCP (Ken Turkowski) (06/04/85)
In article <520@x.UUCP> john@x.UUCP (John Woods) writes: >> I've had a number of responses on how to remove the file whose name is >> \t 360 200 035 002 \0 >> but no one has won yet. Most people recommended using unlink(2) like this: >> main() { >> unlink("\t\360\200\035\002"); >> } >> but this fails. ... >> That failed too. Holy filename, Batman! What next? >> Jeff Percival ...!uwvax!uwmacc!jwp > >If that fails, you must have the "`feature'" turned on where 2.9 strips >out "`illegal'" characters in file names. If so, you have one-and-a-half >options: >(.75) Go to your kernel sources, remove that feature, bulk-erase your >distribution tape so it will never come back, recompile and reboot. Then >do the unlink, unmolested by malfeatures. >(1.5) Open the raw disk for writing with adb. When I have to patch disks >by hand, I always print up extra copies of section 5 of the manual to >have them arrayed in front of me... > >If you don't have sources, you're stuck with the second. Neither of them >is enjoyable, but at least the first cures it forever. You can also zap the inode with clri, and let fsck remove it. -- Ken Turkowski @ CADLINC, Menlo Park, CA UUCP: {amd,decwrl,hplabs,nsc,seismo,spar}!turtlevax!ken ARPA: turtlevax!ken@DECWRL.ARPA
wcs@ho95b.UUCP (Bill Stewart) (06/05/85)
The best approach is "rm -i", if you have it. Some other options - If you have emacs available, see if you have "dired". It's an emacs package for editing directories (using system calls rather than directly hacking the files.) "fsdb" is a System III/V program that looks a lot like adb but knows about inodes and directories. Unmount the disk and hack away, using either one.
spaf@gatech.CSNET (Gene Spafford) (06/05/85)
Let me suggest the following:
1) do an ls -i and the the inode number of your funny file.
2) unmount the disk
3) Use "clri" to zero out the inode of the funny file (I hope you
have "clri" ! It should be in /etc)
4) Run fsck to straighten out the unclaimed data blocks
5) remount your disk
I've used this procedure before to kill funny directories and it works
just fine.
--
Gene "3 months and holding" Spafford
The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332
CSNet: Spaf @ GATech ARPA: Spaf%GATech.CSNet @ CSNet-Relay.ARPA
uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spaf