help removing a file

[Gary Bridgewater]

In article <26428 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
>In article <1990Sep6.183808.20578 at Matrix.COM> abc at Matrix.COM (Alan Clegg)
>writes:
>>Well, I managed to get a file with a '/' (slash) in its name ...
>>Anyway, it seems to me that DUMP/RESTORE should look for 'badness' in file
>>names (or maybe not).
>>
>>****** What DUMP writes, RESTORE should be able to restore. *******
>
>Well, yes and no.  In this case the bug is not in either dump or restore,
>but rather in fsck, which permitted an invalid name to remain.

I don't recall Alan mentioning that he ran fsck.  I know pre-AViiON DG/UX
was quick to catch funny characters in file names and, with approval,
hie them to lost+found.   Since I haven't had one on my AViiON I won't
swear it will do the same thing but I suspect sure it will.  (How about
it Alan, did you?)
Perhaps an enhancement to dump would be in order - that it use the same
file name validation code that fsck does and refuse to deal with bogus
names - by aborting (boo), refusing to include the file, renaming it
on the fly (possibky dangerous) to some obscure name (e.g. XXXXXXXXXXX01)
or replacing the offending characters with something like ','.  Even if you
end up with multiple files named the same thing, using either of the last
two possibilities, you can recover from that if restore can, somehow,
create them.
Is there any reason, short of appealing to history, that fsck and
dump/restore have to be ignorant of each other's operation?  That they
have different functions shouldn't mean they can't share the code.
Are there organizations that count on un-dumpable/restorable file names
for a weak form of security or some other reason?
-- 
Gary Bridgewater, Data General Corporation, Sunnyvale California
gary at sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary
C++ - it's the right thing to do.