guy@auspex.auspex.com (Guy Harris) (02/03/91)
>This won't work. The / is not interpreted by the shell, but by the >kernel routine namei(), which translates file names into inode numbers. Actually, it's not called "namei()" in SunOS, but that's an extremely minor detail; your explanation is correct, and your suggested fix is mostly correct, except that you probably want to unmount the file system *before* doing the "clri". However, if you end up nuking the inode for the file, you've lost that file. Another possibility is to make another directory at the same level as the one containing the file with the "/" in its name, move all the other files into that directory (including files with names beginning with ".", other than "." and "..", if any exist), do "ls -id" on the directory containing that file, unmount the file system, nuke that *directory's* inode with "clri", and then do an "fsck". "fsck" should make a new link to the file with the bad name in "lost+found", so you won't lose the file. Then renmae the newly-created directory to have the name of the old directory, and move the file from "lost+found" into that directory with some name (not containing a "/", needless to say...). I suspect the bad file got there because of a Mac or maybe PC or some other non-UNIX NFS or perhaps Tops client. There's a bug in older versions of the Sun NFS server code (probably inherited by some other vendors; we've gotten rid of that bug, and so has Sun in SunOS 4.1) where it doesn't check for "/" in file names coming over the wire, but instead creates files with "/" in their name. If that's the case, another alternative fo rdealing with the file might be to find out who created it, and have *them* rename it; the same NFS server bug that let them create the file in the first place should let them rename it to something nicer....
mcf@trlamct.trl.oz.au (Michael Flower) (02/04/91)
From article <821@nddsun1.sps.mot.com>, by cowan@dover.sps.mot.com (Andrew H Cowan): > > Now that I've got 'em, how can I get rid of them? > This looks like a job for fsdb. I don't know however if fsdb is generally available, however it can be used to modify the directory entry with this awful filename in it. It will be necessary to determine the inode # of the offending directory (using ls -i), then examine the inode with fsdb, determine the directory blocks and modify the appropriate entry in the appropriate block (ie. replace the `/` in the filename). The problem is NOT fixable using other UNIX commands, since they all reference the file via namei, which knows about '/' as being a path component seperator. Using clri will lose the file altogether. This might not be a good idea. Hope I am not too far off beam. cheers ...mcf Michael Flower Artificial Intelligence Systems Email: flower@trl.oz.au Telecom Research Laboratories Voice: +61 3 541 6179 Melbourne, AUSTRALIA Fax: +61 3 543 8863
shore@mtxinu.COM (Melinda Shore) (02/05/91)
In article <2665@trlluna.trl.oz> mcf@trlamct.trl.oz.au (Michael Flower) writes: >The problem is NOT fixable using other UNIX commands, since they all reference >the file via namei, which knows about '/' as being a path component >seperator. This is not really true. adb is certainly up to the job, and I suspect that emacs could do the trick, too. As long as you can get into the raw device you have many options for changing the filename. -- Software longa, hardware brevis Melinda Shore shore@mtxinu.com mt Xinu ..!uunet!mtxinu.com!shore
rodney@dali.ipl.rpi.edu (Rodney Peck II) (02/06/91)
>>>>> On 4 Feb 91 23:13:54 GMT, shore@mtxinu.COM (Melinda Shore) said: > In article <2665@trlluna.trl.oz> mcf@trlamct.trl.oz.au (Michael Flower) writes: >The problem is NOT fixable using other UNIX commands, since they all reference >the file via namei, which knows about '/' as being a path component >seperator. hey people -- this 'how do I delete a file with a / in it' and it's cousin question 'how do I delete a file that starts with -' are in the FAQ. They are the reason that the FAQ was made, and a large part of the reason that the wizards group was split apart. The answer -- the real answer -- is in the FAQ for this group. Go look in the spool dir for the oldest file for this group -- that's probably it. -- Rodney
barmar@think.com (Barry Margolin) (02/06/91)
In article <RODNEY.91Feb5155821@dali.ipl.rpi.edu> rodney@dali.ipl.rpi.edu (Rodney Peck II) writes: >hey people -- this 'how do I delete a file with a / in it' and it's cousin >question 'how do I delete a file that starts with -' are in the FAQ. Where? I just looked at the comp.unix.questions FAQ, and it only addressed the problem of filenames beginning with "-" and filenames containing characters that are special to the shell. Filenames containing "/" really do require wizardly powers to deal with. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
enag@ifi.uio.no (Erik Naggum) (02/06/91)
In article <HGJ.91Feb5193804@sage.cc.purdue.edu> hgj@sage.cc.purdue.edu (hgj) writes: > ... For the / character, I would reccomend editing the directory > (dired/dired.el) and renaming it to something harmless. Or, if you > really want to teach yourself not to do it again, write a C program > to change the name field of the proper inode struct. (Relatively > easy, I would imagine) Wrong. `/' in the file name cannot be cured even by Emacs. Also, there's no "name field" in the inode. Names are contained in special files called directories, which have an inode number and a name for each entry (at least). > Anyways, no need to get drastic or root in either case. Sadly, yes, there is. -- [Erik Naggum] <enag@ifi.uio.no> Naggum Software, Oslo, Norway <erik@naggum.uu.no>
ewoods@hemel.bull.co.uk (Eoin Woods) (02/07/91)
enag@ifi.uio.no (Erik Naggum) writes: >In article <HGJ.91Feb5193804@sage.cc.purdue.edu> hgj@sage.cc.purdue.edu (hgj) writes: >> ... For the / character, I would reccomend editing the directory >> (dired/dired.el) and renaming it to something harmless. Or, if you >> really want to teach yourself not to do it again, write a C program >> to change the name field of the proper inode struct. (Relatively >> easy, I would imagine) >Wrong. `/' in the file name cannot be cured even by Emacs. Also, >there's no "name field" in the inode. Names are contained in special >files called directories, which have an inode number and a name for >each entry (at least). >> Anyways, no need to get drastic or root in either case. >Sadly, yes, there is. As Erik says, yes there is -- The only way to get rid of it is to modify the filesystem directly through its raw device -- Use fsdb if its available on your system. If not, get writing some C :-( (or delete the whole file system and restore from backups :-( ) Eoin. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Eoin Woods, Software Development Group, Bull HN Information Systems, ~ ~ Maxted Road, Hemel Hempstead, Herts HP2 7DZ, UK. ~ ~ Tel : +44 442 232222 x4823 Fax : +44 442 234084 ~ ~ < Eoin.Woods@hemel.bull.co.uk or ...!uunet!ukc!brno!ewoods> ~ ~ < When do we start news group comp.os.emacs ? :-) > ~
sahayman@porbeagle.cs.indiana.edu (Steve Hayman) (02/08/91)
I've added this section to the FAQ answer about removing files with
strange characters in their names. Please email me any corrections or
additions. Thanks.
If the filename has a slash in it, you have a bigger problem.
Recall that Unix directories are simply pairs of
filenames and inode numbers. A directory essentially
contains information like this:
filename inode
file1 12345
file2.c 12349
file3 12347
Theoretically, '/' and '\0' are the only two characters that
cannot appear in a filename - '/' because it's used to separate
directories and files, and '\0' because it terminates a filename.
Unfortunately some implementations of NFS will blithely create
filenames with embedded slashes in response to requests from remote
machines. For instance, this could happen when someone on a Mac or
other non-Unix machine decides to create a remote NFS file on
your Unix machine with the date in the filename. Your Unix
directory then has this in it:
filename inode
91/02/07 12357
No amount of messing around with 'find' or 'rm' as described above
will delete this file, since those utilities and all other Unix
programs, are forced to interpret the '/' in the normal way -
those programs will think that "91" is a directory.
What can you do in this case?
The first thing to try is to return to the Mac that created this
crummy entry, and see if you can convince it and your local NFS
daemon to rename the file to something without slashes.
If that doesn't work or isn't possible, drastic action by root is
required. Use "ls -i" to find the inode number of this bogus
file, then unmount the file system and use "clri" to clear the
inode, and "fsck" the file system with your fingers crossed.
This destroys the information in the file. If you want to
keep it, you'll have to patch the directory the hard way
by crawling around in the raw file system.
Use "fsdb", if you have it, otherwise start learning "adb".
..Steveallbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (02/10/91)
As quoted from <1991Feb4.231354.5305@mtxinu.COM> by shore@mtxinu.COM (Melinda Shore): +--------------- | In article <2665@trlluna.trl.oz> mcf@trlamct.trl.oz.au (Michael Flower) writes: | >The problem is NOT fixable using other UNIX commands, since they all reference | >the file via namei, which knows about '/' as being a path component | >seperator. | | This is not really true. adb is certainly up to the job, and I suspect | that emacs could do the trick, too. As long as you can get into the raw | device you have many options for changing the filename. +--------------- (GNU) Emacs won't do the job unless you've munged VALBITS and GCTYPEBITS to be different from the standard, or you like 8MB filesystems. And even with the changed values, you're still limited to 32MB filesystems. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
alter@ttidca.TTI.COM (Steve Alter) (02/14/91)
At last, a package that avoids this problem altogether!
I'm installing and testing the uShare software from Information
Presentation Technologies, Inc. It provides, among other things, an
AppleShare Server daemon for SunOS systems. I don't know if anybody
else does this (yet) but uShare prevents the '/' from getting into the
filename in the first place.
When you create a file from a Mac in a uShare AppleShare volume, any
characters that Unix might not like (slashes, control characters, bytes
with the 8th bit, etc.) are converted into some strange notation
(possibly hexadecimal digits) and prefixed with a ':'. Since the colon
is invalid as part of a Mac filename (it's used to separate folder
names in a path and the "Save File" dialog either ignores it or turns
it into a hyphen) it's certainly available to protect the filename on
the Unix side.
--
Steve Alter <alter@ttidca.tti.com>
{philabs,psivax,pyramid,quad1,rdlvax,retix,rutgers}!ttidca!alter
Transaction Technology Inc. a subsidiary of Citicorp (213) 450-9111 x2541gwyn@smoke.brl.mil (Doug Gwyn) (02/17/91)
In article <Feb.16.11.29.52.1991.575@remus.rutgers.edu> rauscher@remus.rutgers.edu (Rich Rauscher) writes: >Yeh, it's possible to type this but in almost all versions >of Unix, you'll just get an error 'No such >file or directory' or something like it. This will >happen whether you're in a shell or application. Look, guys, if you feel obligated to drag this discussion out, you should go back and check the posting that started it. The problem is not that a user DESIRED to have a pathname COMPONENT with a slash embedded in it; the problem is that a deficient implementation ALLOWED one to be created, but it was much more difficult to fix the situation once it had occurred. If you don't by now know how this could have occurred, you should not be prolonging the discussion.
donn@hpfcdc.HP.COM (Donn Terry) (02/20/91)
Having once had the joy ( :-} ) of dealing with a version of fsck(!) that would create filenames with imbedded nulls in them (even worse than imbedded slashes because they don't print right!), the discussion about how to remove such filenames is correct: you can't do it easily. I know of several ways (without going back to the offending software if it is even capable of undoing the damage).: Use fsdb to patch the filename field of the directory entry. Be sure you don't make things worse (like imbed a null). (In theory this doesn't require a fsck, but in theory all unused guns are always unloaded, too.) Use fsdb to zero the i-number field of the diretory entry, and fsck to get the link count back to the right value. (Only experienced fsdb users should use fsdb; there's a catch-22 here that should be taken with a grain of salt: fsdb is hard to use and error-prone.) The clri trick mentioned here earlier. The trick of linking all good files and nuking the directory. However this may leave it in lost+found, instead. Write a C program that does one of the above actions to the open raw file system. (Probably worse than using fsdb because finding the right place is hard.) Have a version of fsck that looks for such junk and fixes it. Some exist, and if you have source it's probably easier to fix it in fsck than learning fsdb (which is not to say that fixing it in fsck is trivial, but not's not too hard). I guess you could back up everything (else) and reinitialize the media, but I'd rather not. Donn Terry HP, Ft. Collins