Messages in this thread | | | Date | Tue, 16 Feb 1999 14:39:39 -0800 (PST) | From | (Scott Lurndal) | Subject | Re: rmdir of a busy directory |
| |
In article <7a8mn3$5hquh@fido.engr.sgi.com>, Martin Tessun <martin.tessun@class.de> writes: |> Thierry Danis wrote: |> > You are able to unlink a file that is opened and used by yourself |> > or another process. |> > You are able to rmdir your current directory by typing |> > rmdir `pwd`. So I do not see why we should take care of the |> > name of the directory to reject the deletion (`pwd` versus '.'). |> |> That exactly isn't correct (at least in Solaris 2.5.1). See my posting |> on the list to the topic |> |> rmdir of one's pwd (was Re: rmdir of a busy directory) |> |> There you see, that SunOS 5.5.1 returns EINVAL also on rmdir `pwd`. As I |> now understand I think EBUSY isn't correct, because you can remove a |> busy directory. As rmdir() doesn't delete the cwd it should be EINVAL. I |> think the soluton Alexander added is the correct one.
From the standards standpoint, the following text applies to unlink() when targetting a directory and to rmdir():
unlink(): ...
[EBUSY] The directory named by the path argument cannot be unlinked because it is being used by the system or another process and the implementation considers this to be an error.
rmdir():
[EBUSY] The directory named by the path argument cannot be removed because it is being used by another process and the implementation considers this to be an error.
So, according to Posix (and by extension, the single unix specification), there are two choices:
1) The implementation allows an existing directory with a non-zero active reference count to be removed and returns a success indication, or
2) The implementation returns EBUSY.
Nothing else is allowed by the specifications for this condition.
(The weasel wording is there to allow for the fact that some BSD implementations differed in the handling of rmdir from SYSV derived implementations - so both methods were standardized. This does in no way allow operating system implementors to invent a new error code for an existing condition).
(And Steven Tweedie writes: > > Even stranger, attempts to creat() or mkdir() in the nonexistent > > directory yield EPERM.
> That is correct behaviour.
The standards would appear to mandate ENOENT for this condition:
from open(): (and by derivation, creat):
[ENOENT] ... O_CREAT is set and either the path prefix does not exist or the path argument points to an empty string.
It is clear that after the current working directory has been removed (on implementations which support such an operation), the path prefix (implicitly './') does not exist and the operation should return ENOENT, not EPERM.
While POSIX and the Single Unix Specification both allow additional errno values to be returned for interfaces under conditions not specified, an implementation may not return an alternate error code for a condition that has been specified to return a particular error code.
scott lurndal (slurn@engr.sgi.com)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |