Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!wmartin@almsa-1.arpa
From: wmartin@almsa-1.arpa (Will Martin -- AMXAL-RI)
Newsgroups: comp.unix.questions
Subject: Re:  Accessing files by inode #s
Message-ID: <11667@brl-adm.ARPA>
Date: 5 Feb 88 22:25:43 GMT
Sender: news@brl-adm.ARPA
Lines: 47

I've gotten quite a few pointers to using "rm -i *" (or some subset of
"*") for the remove-weird-named-file problem. However, it doesn't work 
in every case. I have one right now in my home directory which will show
up in an "ls -lt" listing as "?ol?". If I do an "rm ?ol?" or "rm -i ?ol?",
I get "rm: hold non-existent" as the response.

An "ls -l ?ol?" will get "cannot stat hold" as the response. Notice that
the commands can say "hold" in these cases, and not "?ol?". They CAN find
this file, but they then cannot work upon it. An "od -c ." will
produce output in which I can find the offending file with its name
interpreted as "350 o l 344". 

Interestingly, this file only shows up in an "ls -lt" listing, but not
in any other "ls" output I've tried where I don't use the "-t" option.
When I let it print on the screen, the filename shows up as "?ol?" but
when I redirect the output to a file, the filename comes out "hold",
like this:
-rw-------  1 wmartin      4781 Jan 11 15:09 hold

This file had gotten created by my fumble-fingered typing when I was
trying to move a message into a standard message file I normally use
named "hold" (I have since moved all the messages out of the real "hold"
file and deleted it while this bogus file exists).

In short, I thank all those who sent me responses, but I wouldn't have
pestered the list if something obvious like "rm -i" would have worked.
I understand now that links prevent a simple backwards reference from
inode # to filename, and this does answer my original question about
why there was no "remove by inode #" option to "rm". At least one
respondent sent me a C program which will do this function, though,
so it can be done if you know the file doesn't have links.

You can also use "find" to do this, and several respondents sent me
pointers on that method. I will experiment with them. Since they all
seem to rely on "rm" working on the file after you locate it, and, as
you can see above, rm can already locate the file but fails in the
remove process, I wonder how useful these methods are.

One last point -- please note that this originates on the ARPA/MILNET,
and, even though you may be reading it in a USENET newsgroup, not
everyone has access to things like the "answers to frequently-asked
questions" posted in the newusers newsgroups. Those don't exist over
here in ARPA mailing-list land.

Regards,
Will Martin
wmartin@ALMSA-1.ARPA   (on USENET try "...!uunet!almsa-1.arpa!wmartin")