wheels@mks.UUCP (Gerry Wheeler) (11/26/88)
For some reason, my rmdir doesn't work any more. It used to work.
I think. (This is on MINIX ST.)
I can see the directory with ls -l, but if I try rmdir foo, I get an
error message from rmdir saying foo does not exist. I looked in the
code, and this will print if rmdir gets an error stat'ing the file.
Where should I look next?
--
Gerry Wheeler Phone: (519)884-2251
Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels
35 King St. North BIX: join mks
Waterloo, Ontario N2J 2W9 CompuServe: 73260,1043hcj@lzaz.ATT.COM (HC Johnson) (11/28/88)
<rmdir has become blind The commonest cause of a file or directory that cannot be removed is that there are non printing characters as part of the name. ls | od -c will often show the culprit. rm -fr is often the only way to deal with such names. Howard C. Johnson ATT Bell Labs ...lzaz!hcj
wpohl@hvrunix.UUCP (Walter E. Pohl) (11/29/88)
In article <579@mks.UUCP>, wheels@mks.UUCP (Gerry Wheeler) writes: > I can see the directory with ls -l, but if I try rmdir foo, I get an > error message from rmdir saying foo does not exist. I looked in the > code, and this will print if rmdir gets an error stat'ing the file. > Where should I look next? > -- > Gerry Wheeler Phone: (519)884-2251 I had this problem once or twice on Minix PC. I was able solve the problem by checking the file system. Assuming that Minix ST is similar to Minix PC (a not unreasonable assumption), there should be an option when you boot up to verify the file system. During verification, it will ask you questions. It will probably ask you one to the effect of deleting foo. You should answer yes. If this isn't detailed enough, reply, and I'll try to remember more exactly. -- Walt Pohl (Haverford College) UUCP: {rutgers, uunet} !cbmvax!vu-vlsi!hvrunix!wpohl BITNET: w_pohl@hvrford, or walt@brynmawr
mjs@whuts.ATT.COM (SCHEUTZOW) (11/30/88)
>> I can see the directory with ls -l, but if I try rmdir foo, I get an >> error message from rmdir saying foo does not exist. I looked in the >> code, and this will print if rmdir gets an error stat'ing the file. > The commonest cause of a file or directory that cannot be removed > is that there are non printing characters as part of the name. > I had this problem once or twice on Minix PC. I was able solve > the problem by checking the file system. On my copy of minix (ibmpc v1.2) the "rmdir" program does not have the suid bit set. This means that root can remove directories, but ordinary users don't have sufficient privilege. This makes it appear that the command "suddenly" stops working. Login as root and change directory to /usr/bin. Set this bit using the command: # chmod 4755 rmdir This cleared up the problem for me. Mike S. att!whuts!mjs
mjs@whuts.ATT.COM (SCHEUTZOW) (11/30/88)
> On my copy of minix (ibmpc v1.2) the "rmdir" program does not have the > suid bit set. > # chmod 4755 rmdir > Oops! I was referring to the copy on my harddisk, not the one on the floppy. Of course, you'all knew that :-). Mike S. att!whuts!mjs
wheels@mks.UUCP (Gerry Wheeler) (11/30/88)
In article <579@mks.UUCP>, wheels@mks.UUCP I wrote: > I can see the directory with ls -l, but if I try rmdir foo, I get an > error message from rmdir saying foo does not exist. In article <474@hvrunix.UUCP>, wpohl@hvrunix.UUCP (Walter E. Pohl) writes: > I had this problem once or twice on Minix PC. I was able solve > the problem by checking the file system. Thanks to all the people who have emailed and posted possible solutions to this. I still haven't figured it out. Some suggested that rmdir needed to be setuid to root, and it is. In addition, I was logged in as root when these problems happened. Some suggested there might be a non-printable character in the file name, but there isn't. Last night I had a couple of minutes to play, so I did this: $ cd /tmp $ mkdir foo $ rmdir foo rmdir: cannot delete "foo" This behaviour is different from before, but still irritating. I'll keep digging. Keep those cards and letters coming in. Oh, one way I have found to violently dislodge a directory is to run cc and tell it to use as output a name which is an unwanted directory. It eventually gives an error message that the file already exists, but in the process it deletes it. I then run fsck to fix the file system. In this case, it does what I want. I'm not sure this behaviour is normally desireable, however. Be careful when you call cc. -- Gerry Wheeler Phone: (519)884-2251 Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels 35 King St. North BIX: join mks Waterloo, Ontario N2J 2W9 CompuServe: 73260,1043
allbery@ncoast.UUCP (Brandon S. Allbery) (12/08/88)
As quoted from <586@mks.UUCP> by wheels@mks.UUCP (Gerry Wheeler): +--------------- | Oh, one way I have found to violently dislodge a directory is to run cc | and tell it to use as output a name which is an unwanted directory. It | eventually gives an error message that the file already exists, but in | the process it deletes it. I then run fsck to fix the file system. In | this case, it does what I want. I'm not sure this behaviour is normally | desireable, however. Be careful when you call cc. +--------------- Don't blame ast for this -- a reasonably pure System V's pcc does this as well. I managed to orphan a directory tree my mis-specifying the arguments in a Makefile while attempting to build a new kernel: $ sh :mkuts86 (deleted) cc (...) -o .. ld: cannot create .. *** Exit 13. Stop. $ ls .. .. not found $ _ Summary: cc is an idiot. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
wheels@mks.UUCP (Gerry Wheeler) (12/09/88)
In article <13220@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) writes: > stuff not necessarily relevant, but it reminded me to post this... I finally figured out what had happened to rmdir. It's fixed not, but it raises another question. The problem was that, although rmdir was chmod'ed to setuid, it was owned by bin instead of root. I must have done that when I was doing some housecleaning. The question is this: what is the purpose of the bin userid? Why not just have all the stuff owned by root? Would there be a possible security hole? (Remember, 'though I've used Unix, and now MINIX, I've never had to do all this sysadmin stuff before. No major flames, please.) -- Gerry Wheeler Phone: (519)884-2251 Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels 35 King St. North BIX: join mks Waterloo, Ontario N2J 2W9 CompuServe: 73260,1043
henry@utzoo.uucp (Henry Spencer) (12/10/88)
In article <595@mks.UUCP> wheels@mks.UUCP (Gerry Wheeler) writes: >The question is this: what is the purpose of the bin userid? Why not >just have all the stuff owned by root? ... The main idea is simply to make it possible to do system work without having to be root. Being root is dangerous, since it bypasses the whole protection system, and many types of system work don't require it, so long as it is possible to write on system files. Having said files owned by an otherwise-ordinary userid permits this. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu