Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!caen!zaphod.mps.ohio-state.edu!samsung!know!news.cs.indiana.edu!sahayman@porbeagle.cs.indiana.edu From: sahayman@porbeagle.cs.indiana.edu (Steve Hayman) Newsgroups: comp.unix.internals Subject: Re: Help! There's a slash '/' in my filename. Message-ID: <1991Feb7.162253.20326@news.cs.indiana.edu> Date: 7 Feb 91 21:22:38 GMT References: <1991Feb4.231354.5305@mtxinu.COM> <1991Feb6.044821.12311@Think.COM> Organization: Computer Science, Indiana University, Bloomington. Lines: 52 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". ..Steve