harmon@function.mps.ohio-state.edu (Jim Harmon) (09/06/90)
Could someone someone help me with removing a file. On our system we have a file that appears as zhang?evai.tex when doing a `ls` but a tab completion says it's zhangNevai.tex. I've tried putting a back slash in front of the ? and quoting the whole name. I even tried doing `rm -i *` and it matches zhangNevai.tex but says there's No such file or directory. thanks harmon@mps.ohio-state.edu
gupta@ux1.cso.uiuc.edu (Rohit Gupta) (09/06/90)
harmon@function.mps.ohio-state.edu (Jim Harmon) writes: >says it's zhangNevai.tex. I've tried putting a back slash in front of the ? >and quoting the whole name. I even tried doing `rm -i *` and it matches >zhangNevai.tex but says there's No such file or directory. Try using its inode to remove it. First do an 'ls -i' to determine its inode number. Lets say that this returns 33007. Next enter the following: find . -inum 33007 -exec rm {} \; That should remove it. Rohit -- -------------------- Rohit Gupta -------- (217)244-1205 -------------------- Internet:rohit@uiuc.edu UUCP:uunet!uiucuxc!ux1!gupta BITNET:GUPTA@UIUCVMD --------------- University of Illinois Computing Services Office ------------
josef@nixpbe.UUCP (Moellers) (09/06/90)
In <1990Sep5.180847.21767@zaphod.mps.ohio-state.edu> harmon@function.mps.ohio-state.edu (Jim Harmon) writes: >Could someone someone help me with removing a file. On our system we have a >file that appears as zhang?evai.tex when doing a `ls` but a tab completion >says it's zhangNevai.tex. I've tried putting a back slash in front of the ? >and quoting the whole name. I even tried doing `rm -i *` and it matches >zhangNevai.tex but says there's No such file or directory. My preferred solution to this kind of problems (You'll never guess how many people take the left arrow key to be the backspace key, and then you end up with filenames like .prifi^[[D^[[D^[[Dofile): do an 'od -c .", then try to find the offending entry (easy with SysV, not so easy with bsd). Then remove that file. -- | Josef Moellers | c/o Nixdorf Computer AG | | USA: mollers.pad@nixbur.uucp | Abt. PXD-S14 | | !USA: mollers.pad@nixpbe.uucp | Heinz-Nixdorf-Ring | | Phone: (+49) 5251 104662 | D-4790 Paderborn |
mvadh@cbnews.att.com (andrew.d.hay) (09/06/90)
In article <1990Sep5.180847.21767@zaphod.mps.ohio-state.edu>, harmon@function.mps.ohio-state.edu (Jim Harmon) writes: > Could someone someone help me with removing a file. On our system we have a > file that appears as zhang?evai.tex when doing a `ls` but a tab completion > says it's zhangNevai.tex. I've tried putting a back slash in front of the ? > and quoting the whole name. I even tried doing `rm -i *` and it matches > zhangNevai.tex but says there's No such file or directory. also try ls -lb; the l will give you lots of infornation such as size, type, permissions, etc. and the b will print control characters (if any) in the name as \XXX. -- Andrew Hay +------------------------------------------------------+ Ragged Individualist | You just have _N_O idea! It's the difference | AT&T-BL Ward Hill MA | between _S_H_O_O_T_I_N_G a bullet and _T_H_R_O_W_I_N_G it! | a.d.hay@att.com +------------------------------------------------------+
billr@samsung.com (Bill Russell) (09/06/90)
Try "clri [filesystem] [inode-number]" fsck will then get rid of it.
eliot@dg-rtp.dg.com (Topher Eliot) (09/06/90)
In article <1990Sep5.180847.21767@zaphod.mps.ohio-state.edu>, harmon@function.mps.ohio-state.edu (Jim Harmon) writes: |> Could someone someone help me with removing a file. ... |> I even tried doing `rm -i *` and it matches |> zhangNevai.tex but says there's No such file or directory. If 'rm -i *' fails, it is a bad one indeed. This is just a guess, but perhaps the file name on disk has the high (8th) bit on. If this is the case, and the rm code is turning that bit off somewhere, then that would explain why rm would find the file and then not be able to unlink it. Or perhaps the shell is expanding the '*', but then turning off the 8th bit before passing it to rm. Can you try 'rm -Ri .'? You might have to write a little C program just to unlink it, that passes a filename to the unlink system call without doing anything that would cause the 8th bit of any of the characters to be turned off. As I recall, some versions of ls have an option to print the weird characters in file names as they really are, rather than turning them into '?'. If yours does, you could run such an ls command, and pipe it through 'od -xc' to see what the character is. Hope this helps. -- Topher Eliot Data General Corporation eliot@dg-rtp.dg.com 62 T. W. Alexander Drive {backbone}!mcnc!rti!dg-rtp!eliot Research Triangle Park, NC 27709 (919) 248-6371 Obviously, I speak for myself, not for DG.
durway@dg-rtp.dg.com (Lindsey Durway) (09/07/90)
In article <1990Sep5.180847.21767@zaphod.mps.ohio-state.edu>, harmon@function.mps.ohio-state.edu (Jim Harmon) writes: >Could someone someone help me with removing a file. On our system we have a >file that appears as zhang?evai.tex when doing a `ls` but a tab completion >says it's zhangNevai.tex. I've tried putting a back slash in front of the ? >and quoting the whole name. I even tried doing `rm -i *` and it matches >zhangNevai.tex but says there's No such file or directory. > >thanks >harmon@mps.ohio-state.edu This works for me: Use ls to list file names into a file. Edit the file, removing all but the offending file name. Then insert "rm " at the beginning of the line. Now you have a script that will remove the file--do chmod to make it executable, and run it. -- Lindsey Durway durway@dg-rtp.dg.com -or- ...!mcnc!rti!xyzzy!durway Data General Corp., Research Triangle Park, NC; (919) 248-6166.
abc@Matrix.COM (Alan Clegg) (09/07/90)
In article <1990Sep6.163646.17499@dg-rtp.dg.com> eliot@dg-rtp.dg.com writes: >In article <1990Sep5.180847.21767@zaphod.mps.ohio-state.edu>, >harmon@function.mps.ohio-state.edu (Jim Harmon) writes: >|> Could someone someone help me with removing a file. ... >|> I even tried doing `rm -i *` and it matches >|> zhangNevai.tex but says there's No such file or directory. > >If 'rm -i *' fails, it is a bad one indeed. > Well, I managed to get a file with a '/' (slash) in it's name to appear under DG/UX. No problem, right? Can't remove the sucker, can't mv the sucker, can't even remove '-rf' the directory it lives in... Come around backup time, backups go just fine. Dump dumps and all is right with the world. Come time to restore (having moved the physical disk to a different machine and reformatted it)... RESTORE PUKES WHEN TRYING TO RESTORE GIVEN FILE. ARGH!!! Some bogus error message about not being able to create a directory, then every file after that one goes beserk. USERS ARE ASKING WHEN SYSTEM WILL BE BACK, MANAGEMENT IS ASKING WHEN PROJECTS WILL BE DONE. ALL CURRENT BACKUP TAPES CONTAIN FILE WITH SLASH IN NAME!!! I AM SWEATING BULLETS AND BLOOD (AT THE SAME TIME). WHAT DO I DO? Use interactive restore, restore all directories and all files EXCEPT given 'bad' file. Restores like a charm. No problems at all. 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. ******* -abc -- Alan B. Clegg uucp: ...!mcnc!matrx!abc Matrix Corporation inet: abc@matrix.com Raleigh, NC "They were all wrong. The workstation model is obsolete." A. Tanenbaum
tcurrey@zach.fit.edu ( Thomas E. Currey) (09/07/90)
If its a file try: rm ./... if its a directory: rm -R ./... Because of the ascii character set the '.' is before the '*' and is therefore not picked up but rm. other variations: rm -R ./??. rm -R ./..? Be carefu, they can remove much more.
gt0178a@prism.gatech.EDU (BURNS,JIM) (09/07/90)
in article <1212@tardis.Tymnet.COM>, jms@tardis.Tymnet.COM (Joe Smith) says: > The reason that works is because an executable script that does not start > with "#", "#!/bin/xxx" or ":" is executed by /bin/sh instead of your default > shell, Not on any system I've worked on. It always defaults to $SHELL, your current shell. If this wasn't true, I couldn't use ksh aliases and functions inside my scripts w/o #!/bin/ksh (or whatever). If what you mean is that *csh* defaults to /bin/sh w/o one of your constructs, this is true. -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
bruce@bmhalh.UUCP (Bruce M. Himebaugh) (09/07/90)
In article <1990Sep5.184323.5877@ux1.cso.uiuc.edu> gupta@ux1.cso.uiuc.edu (Rohit Gupta) writes: >harmon@function.mps.ohio-state.edu (Jim Harmon) writes: > >>says it's zhangNevai.tex. I've tried putting a back slash in front of the ? >>and quoting the whole name. I even tried doing `rm -i *` and it matches >>zhangNevai.tex but says there's No such file or directory. > >Try using its inode to remove it. First do an 'ls -i' to determine its inode >number. Lets say that this returns 33007. Next enter the following: > > find . -inum 33007 -exec rm {} \; > >That should remove it. I don't think this will work. The reason being, is that the underlying problem is that the file name has a NULL embedded in it. The way to remove would be the following: 1. Find the inode, using 'ls -i'. 2. Remove the file by clearing the inode (not removing the file). On my system the command is 'clri'. I have had this same problem many times and this was the only way to resolve it. Bruce -- Bruce M. Himebaugh Voice: 216-484-3528 PATHS: uunet!{ncoast,aablue}!fmsystm!bmhalh!bruce (NOTE: the system name "fmsystm" is with no "e", NOT "fmsystem") *NOTE*: Please do not use bruce@bmhalh.UUCP -- I'm not registered yet.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/07/90)
In article <13419@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS,JIM) writes: >in article <1212@tardis.Tymnet.COM>, jms@tardis.Tymnet.COM (Joe Smith) says: >> The reason that works is because an executable script that does not start >> with "#", "#!/bin/xxx" or ":" is executed by /bin/sh instead of your default >> shell, >Not on any system I've worked on. It always defaults to $SHELL, your >current shell. If this wasn't true, I couldn't use ksh aliases and >functions inside my scripts w/o #!/bin/ksh (or whatever). If what you mean >is that *csh* defaults to /bin/sh w/o one of your constructs, this is >true. You clearly ought NOT to be able to use ksh-specific features in shell scripts that others might execute from sh or csh, without forcing ksh to be used via #!/.../ksh in the script. $SHELL is a BIG mistake, and I doubt that even ksh is so broken. Much more likely is that it, like sh, forks itself to process anonymous shell scripts. Ksh can do this since it claims to be upward-com-patible with sh, which is what an anonymous scripts should ALWAYS be assumed to have been written for. The 4BSD csh "feature" that assumes that anonymous scripts starting with # (not #!) should be interpreted by the csh rather than sh is simply a design error in the csh that should have been shorted out when installing csh in a more modern environment. Most sh scripts happen to start with #.
decot@hpisod2.HP.COM (Dave Decot) (09/07/90)
First of all, for the future, BUY SOME MORE DISK PACKS SO YOU DON'T HAVE TO REFORMAT YOUR IMPORTANT DATA BEFORE YOU KNOW IT'S BEEN MOVED CORRECTLY. To solve your current problem, try telling restore not to restore the "directory" in which it appears to be in, if your version of restore has such an option. If it has any option to tell it to continue even after failing to restore a particular file, that would be good to use, too. If not, you can try copying the tape over to another tape while repairing the slash character to be something else. Use grep -b /dev/<tape> to locate the tape block on which this name occurs. Use the no-rewind versions of /dev/<tape> and /dev/<tape2> (another tape drive with a scratch tape of the same size on it) in a combination of dd(1), cat(1), and some kind of binary editor to make a repaired copy of tape. The mt(8) command may be of some use here, as well; I don't know. It's too bad there's no tape editor on Unix. Good luck. I don't think this is too easy a project. Dave Decot
rns@se-sd.SanDiego.NCR.COM (Rick Schubert) (09/08/90)
In <1990Sep5.180847.21767@zaphod.mps.ohio-state.edu> harmon@function.mps.ohio-state.edu (Jim Harmon) writes: >Could someone someone help me with removing a file. On our system we have a >file that appears as zhang?evai.tex when doing a `ls` but a tab completion >says it's zhangNevai.tex. I've tried putting a back slash in front of the ? >and quoting the whole name. I even tried doing `rm -i *` and it matches >zhangNevai.tex but says there's No such file or directory. I've seen about 6-8 follow-ups to this question, and none gave a very general solution (some might work with some versions of `ls' and/or some shells and/or some versions of `find' some might work depending on what the non-printable characters are, while others won't work at all, anywhere). The most general solution is to execute (assuming you are in the directory with the offending file): rm -ri . Then `rm' will prompt you for each of the files in the current directory and those under it (unfortunately, although if you answer "n" when it first encounters the directory, `rm' will not traverse the subdirectory). Answer "n" to all of those except the one(s) you want removed. The key is to avoid generating the filename on the command line (with or without wildcards). I was surprised to see this question posted to comp.unix.admin, but I was even more surprised at the poor quality of the answers. But I don't mean to start a flamefest. -- Rick Schubert (rns@se-sd.sandiego.NCR.COM)
guy@auspex.auspex.com (Guy Harris) (09/08/90)
>My preferred solution to this kind of problems (You'll never guess how >many people take the left arrow key to be the backspace key, and then >you end up with filenames like .prifi^[[D^[[D^[[Dofile): >do an 'od -c .", then try to find the offending entry (easy with SysV, >not so easy with bsd). Not so easy with S5R4, either, if you're using the BSD file system (or, for that matter, with any other S5 system that supports the BSD file system - or, perhaps, other file systems, such as SGI's Extent File System, which may also use a different directory format). Fortunately, in S5R4, you can do "stty echoctl" and have the left-arrow key echo as "^[[D" just as it does in BSD, which should help convince people that it's *not* the backspace key.
guy@auspex.auspex.com (Guy Harris) (09/08/90)
>I have found that the C-shell from Sun (BSD) strips off the 8th bit of all >arguments passed to any program. Yup; UNIX shells have traditionally used the 8th bit internally for quoting, and strip it off before passing arguments. AT&T fixed the Bourne shell in S5R3, and that version of the Bourne shell is the basis of the one in SunOS 4.x. Sun fixed the C shell in SunOS 4.1, and that version of the C shell is the basis of the one in S5R4.
chris@mimsy.umd.edu (Chris Torek) (09/08/90)
In article <1990Sep6.183808.20578@Matrix.COM> abc@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. This bug is fixed in 4.3BSD-reno (fsck/dir.c, routine dirchk). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
peter@ficc.ferranti.com (Peter da Silva) (09/08/90)
In article <13419@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS,JIM) writes: > Not on any system I've worked on. It always defaults to $SHELL, your > current shell. No, you mean ksh defaults to ksh. On every system I've ever used, sh defaults to sh and csh uses the # hack to decide if it should use sh or csh. In my opinion, this is an error: ksh should execute scripts with /bin/sh by default... there are enough differences in behaviour between the two shells that this can break stuff. Just try replacing "sh" with "ksh" to see what I mean. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
gt0178a@prism.gatech.EDU (BURNS,JIM) (09/08/90)
in article <13766@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) says: > You clearly ought NOT to be able to use ksh-specific features in shell > scripts that others might execute from sh or csh, without forcing ksh to > be used via #!/.../ksh in the script. $SHELL is a BIG mistake, and I > doubt that even ksh is so broken. Much more likely is that it, like sh, > forks itself to process anonymous shell scripts. Ksh can do this since Yes, ksh does fork itself, as you can tell from a ps listing (from another window) of any long running or interactive anonymous script started from ksh. Refering to $SHELL was a euphemism, and as such a mis-statement. Whether you and Peter DaSilva want to "fix" ksh so that anonymous scripts use /bin/sh, and "fix" csh so that a first line of '#' has no special meaning is a design question I have no opinion on (other than any script implementer has to be aware of these 'gotchas'). Obviously, if I post a script for public consumption on my system, it should have an interpreter line. I was just warning the poster that the assumption that anonymous scripts were always executed by /bin/sh was false. I have never had the occasion to test whether ksh is 8-bit clean (the poster's original point about sh) since either 'find -inum' or 'rm -i' has always worked for me. The recently posted sol'n of 'rm -ri .' is interesting. (Scary, but interesting!) -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
markh@squirrel.LABS.TEK.COM (Mark Henderson) (09/08/90)
In article <1990Sep5.180847.21767@zaphod.mps.ohio-state.edu> harmon@function.mps.ohio-state.edu (Jim Harmon) writes: >Could someone someone help me with removing a file. On our system we have a >file that appears as zhang?evai.tex when doing a `ls` but a tab completion >says it's zhangNevai.tex. I've tried putting a back slash in front of the ? >and quoting the whole name. I even tried doing `rm -i *` and it matches >zhangNevai.tex but says there's No such file or directory. > >thanks >harmon@mps.ohio-state.edu You don't mention what flavour of unix you are using. Here's a simple C program which I keep around called irm, which will allow you to specify an inode number of a file in the current directory and have it deleted. I've been using it for a while on SUN 3's and 4's running SUN OS 4.0.x and Vaxen running 4.3 BSD. I imagine adapting it to almost any flavour of Unix would be easy. It is almost verbatim out of the SUN OS manual entry for directory(3v). It's sloppy in many respects, but then it was a quick hack. For instance I make assumptions about being able to open the current directory, only allow one i-node number to be specified, more or less assume inode numbers are longs, don't check that the parameter is an integer...etc. Use it and modify it absolutely at your own risk. I've placed instructions for using it in the comment. /* * remove a file at a given inode number in the current directory * Mark Henderson, Tektronix, Inc. markh@crl.labs.tek.com * Use this code at your own risk! * Useful for getting rid of files with strange names. Safer * than clri and can be run without being root. * Usage: * irm <inode-number> * The inode number can be obtained by using ls -i * So to get rid of file *****.???'\^C^D^Z * cd into the directory containing the file. * Do an ls -i and find the inode number of the file * (say 30240) then type * irm 30240 * * BSD43 is for VAX BSD 4.3 (do not use BSD43 for SUN OS 4.0) Tested under SUN * OS 4.0 and VAX BSD 4.3. Is BSD43 is not specified compiles for SUN OS 4.0 */ #include <sys/types.h> #include <stdio.h> #ifdef BSD43 #include <sys/dir.h> #else #include <dirent.h> #endif main(argc, argv) int argc; char *argv[]; { ino_t target; DIR *dirp; #ifdef BSD43 struct direct *dp; #else struct dirent *dp; #endif if (argc != 2) { printf("\nusage irm <int>\n"); exit(1); } target = atol(argv[1]); dirp = opendir("."); for (dp = readdir(dirp); dp != NULL; dp = readdir(dirp)) { if ((dp->d_fileno) == target) { printf("\nFOUND: %s\n", dp->d_name); closedir(dirp); if (!unlink(dp->d_name)) printf(" deleted\n"); else printf(" delete failed\n"); exit(0); } } printf("\nNOT FOUND\n"); closedir(dirp); } -- Mark Henderson, Tektronix, Inc., MS 50-662, P.O. Box 500, Beaverton, OR 97077 Telephone: +1 503 627 6280 FAX: +1 503 627 5502 TELEX: 6503784996MCI UW INTERNET: markh@crl.labs.tek.com ATTmail: !mchenderson MCI MAIL: 378-4996 X.400: ADMD=MCI/C=US/Surname=Henderson/Given_Name=Mark/DDA ID=3784996
gary@dgcad.sv.dg.com (Gary Bridgewater) (09/08/90)
In article <26428@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >In article <1990Sep6.183808.20578@Matrix.COM> abc@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@sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary C++ - it's the right thing to do.
karl@ddsw1.MCS.COM (Karl Denninger) (09/09/90)
In article <1990Sep6.183808.20578@Matrix.COM> abc@matrx.UUCP (Alan Clegg) writes: >In article <1990Sep6.163646.17499@dg-rtp.dg.com> eliot@dg-rtp.dg.com writes: >>In article <1990Sep5.180847.21767@zaphod.mps.ohio-state.edu>, >>harmon@function.mps.ohio-state.edu (Jim Harmon) writes: >>|> Could someone someone help me with removing a file. ... >>|> I even tried doing `rm -i *` and it matches >>|> zhangNevai.tex but says there's No such file or directory. >> >>If 'rm -i *' fails, it is a bad one indeed. "rm -i" will fail quite often. There are a number of pathological cases (see one below :-) that will blow rm's puny mind. >Well, I managed to get a file with a '/' (slash) in it's name to appear under >DG/UX. No problem, right? Can't remove the sucker, can't mv the sucker, >can't even remove '-rf' the directory it lives in... One solution to this problem that I've used is to do a "ls -li" on the directory, get the INODE NUMBER, unmount the filesystem (VERY important!) and then, as root, use "clri" to clear the inode. Then run fsck and remount. If it's the root filesystem, clri the inode, sync several times, pray to whichever deity you wish to honor, and hit reset. This ALWAYS works, regardless of the crap you've managed to get into the filename. It's a desparate move, but if rm -i won't work, you may have to do this. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
jms@tardis.Tymnet.COM (Joe Smith) (09/11/90)
In article <30790003@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: >First of all, for the future, BUY SOME MORE DISK PACKS SO YOU DON'T >HAVE TO REFORMAT YOUR IMPORTANT DATA BEFORE YOU KNOW IT'S BEEN MOVED >CORRECTLY. That does not sound like very useful advise to me. I interpret it as "If you are using disk drive with removable media, you should always put the old disk pack on the shelf and format a new pack when you have problems". Ever since we got rid of the RP06, none of our Unix systems have removable disks. Keeping a spare 1.2 gigabyte drive on each and every host is not feasible. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."
rbp@investor.pgh.pa.us (Bob Peirce #305) (09/11/90)
In article <1990Sep5.180847.21767@zaphod.mps.ohio-state.edu> harmon@function.mps.ohio-state.edu (Jim Harmon) writes: >Could someone someone help me with removing a file. On our system we have a >file that appears as zhang?evai.tex when doing a `ls` but a tab completion >says it's zhangNevai.tex. I've tried putting a back slash in front of the ? >and quoting the whole name. I even tried doing `rm -i *` and it matches >zhangNevai.tex but says there's No such file or directory. When confronted with this situation on my system I try mv *zh*tex* foo rm foo The actual regex depends on the problem. The point is that mv seems to be able to work on files where rm won't, so you mv it to a name rm can use. -- Bob Peirce, Pittsburgh, PA 412-471-5320 ...!uunet!pitt!investor!rbp rbp@investor.pgh.pa.us
chris@mimsy.umd.edu (Chris Torek) (09/12/90)
>In article <30790003@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: >>First of all, for the future, BUY SOME MORE DISK PACKS SO YOU DON'T >>HAVE TO REFORMAT YOUR IMPORTANT DATA BEFORE YOU KNOW IT'S BEEN MOVED >>CORRECTLY. In article <1217@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >I interpret [this] as "If you are using disk drive with removable media, you >should always put the old disk pack on the shelf and format a new pack when >you have problems". Ever since we got rid of the RP06, none of our Unix >systems have removable disks. Keeping a spare 1.2 gigabyte drive on each >and every host is not feasible. I rather doubt that Dave Decot is living *that* far in the past :-) Seriously, a better interpretation is: `Have spares. Use them.' Keeping one spare drive, to be used as a replacement when one fails, and to be used to store data that are being moved temporarily, is quite reasonable. Modern SCSI disks are cheap enough ($3800 for 1.2 GB) and reliable enough to buy a baker's dozen, use 12, and keep one as the replacement for whichever fails first. Instead of paying for maintenance, reassign the disk maintenance budget into the new-spares budget. When one *does* fail, slap in the spare and buy a new spare. (Determining the appropriate ratio of spares-to-drives-in-use is what administrative types are supposedly being paid for :-) ) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
gerry@jts.com (G. Roderick Singleton ) (09/16/90)
In article <3812@se-sd.SanDiego.NCR.COM> rns@se-sd.SanDiego.NCR.COM (Rick Schubert) writes: >In <1990Sep5.180847.21767@zaphod.mps.ohio-state.edu> harmon@function.mps.ohio-state.edu (Jim Harmon) writes: > >>Could someone someone help me with removing a file. On our system we have a >> [text deleted] > >I've seen about 6-8 follow-ups to this question, and none gave a very ... > >The most general solution is to execute (assuming you are in the directory >with the offending file): > rm -ri . > >Then `rm' will prompt you for each of the files in the current directory [rick's explanation deleted] > >I was surprised to see this question posted to comp.unix.admin, but I was >even more surprised at the poor quality of the answers. But I don't mean >to start a flamefest. > Perhaps, Rick; but I have a real problem. Directories which can not be removed, period. A solution for this would provide the guidelines needed by our juniour confreres and sure would save me from a newfs and restore. Some background, the system is a Sun 3/280 running SunOS 3.5.x and the faulty directories were inherited from my predecessor who claimed that sccs had a hand in their creation. I keep them in a directory named "BAD INODES" (yes there's a space in the name). Here's the result of ls -lai : BAD INODES: total 6 22610 drwxrwxr-x 3 root wheel 512 Sep 14 21:56 ./ 2 drwxrwxr-x 33 root wheel 1024 Sep 15 15:18 ../ 57369 drwxrwxrwx 5 root wheel 512 Aug 24 20:23 SCCS1.screwup/ 57369 drwxrwxrwx 5 root wheel 512 Aug 24 20:23 SCCS2.screwup/ 57369 drwxrwxrwx 5 root wheel 512 Aug 24 20:23 SCCS3.screwup/ 57369 drwxrwxrwx 5 root wheel 512 Aug 24 20:23 SCCS4.screwup/ By the looks of the above, a simple rmdir or rm -r should remove them BUT no go. Now Rick's method (rm -ir) produced the following: Script started on Sat Sep 15 15:19:21 1990 / >%[101] whoami root / >%[102] cd /usr/kumquat /usr/kumquat >%[103] rm -ri BAD\ INODES rm: remove directory BAD INODES/SCCS2.screwup? y rm: remove BAD INODES/SCCS2.screwup? y rm: BAD INODES/SCCS2.screwup not removed rm: remove directory BAD INODES/SCCS3.screwup? y rm: remove BAD INODES/SCCS3.screwup? y rm: BAD INODES/SCCS3.screwup not removed rm: remove directory BAD INODES/SCCS4.screwup? y rm: remove BAD INODES/SCCS4.screwup? y rm: BAD INODES/SCCS4.screwup not removed rm: remove directory BAD INODES/SCCS1.screwup? y rm: remove BAD INODES/SCCS1.screwup? y rm: BAD INODES/SCCS1.screwup not removed rm: remove BAD INODES? y rm: BAD INODES not removed /usr/kumquat >%[104] script done on Sat Sep 15 15:20:26 199 "Mv"'ing the directories first has also proved fruitless and I haven't had time to write a program to do the job and 'cause I don't know what made these directories non-removable in the first place. Fortunately, they use very little space. I will watch the group with great interest while I await your solutions. Flames? Send them to /dev/null. Thanks, ger -- G. Roderick Singleton, System and Network Manager, JTS Computers {yunexus | uunet | geac | torsqnt}!gerry@jtsv16.jts.com