lkml.org 
[lkml]   [1999]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.024 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site