Andrew,
The current EPERM covers two cases:
1. The named file is a directory and the calling process does not have
appropriate privileges, and
2. The named file is a directory and the implementation prohibits
using unlink() on directories.
Both of these cases have been specified to set errno to EPERM by
POSIX.1 since 1988. Before that, both UNIX System V and 4.3BSD also
set errno to EPERM for both of these cases, and in fact this went back
to at least Version 7. (In Version 7 and System V there was no rmdir()
system call; the unlink() system call was used by a setuid-root process
to remove directories, but 4.3BSD had the rmdir() system call and still
used EPERM for both of these errors.)
If I were inventing a new operating system from scratch today, I would
agree that case 2 should be EISDIR. But I believe it is too late to
rewrite this much history and EPERM should continue to be used for both
of these errors on any UNIX/POSIX system implementation. I see no
reason why applications that have been written to POSIX (1988 through
the present) should be subjected to this arbitrary change in behavior.
Sincerely,
Don
>From yyyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx Wed Apr 10 08:16:53 2002
>Resent-Date: 10 Apr 2002 15:16:06 -0000
>To: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
>From: yyyyyy@xxxxxxxxxxxxx
>Subject: Defect in XSH unlink
>Resent-Message-ID: <yyyyyyyyyyyyyyyyy@xxxxxxx>
>Resent-To: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
>Resent-From: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
>X-Mailing-List: austin-review-l:archive/latest/1145
>X-Loop: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
>Resent-Sender: yyyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx
>
> Defect report from : Andrew Josey , The Open Group
>
>(Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)
>
>@ page 1555 line 47966 section unlink comment {unlink-eisdir}
>
>Problem:
>
>Defect code : 3. Clarification required
>
>The unlink() function defines the following error condition
>
>[EPERM] The file named by path is a directory, and either the calling process
>does not
> have appropriate privileges, or the implementation prohibits using unlink()
> on directories.
>
>
>The EISDIR error condition would also seem an appropriate error
>to return in the case when unlink() is attempted on a directory.
>
>Is an implementation conforming that returns EISDIR rather
>than EPERM ?
>
>A certain body of implementors believe that this is the more
>natural error code to expect in this case.
>
>Action:
>
>Proposed interpretation:
>
>The standard is clear on the requirements, however concerns should
>be forwarded to the sponsor to consider allowing the EISDIR
>error.
>
>
>Proposed rationale:
>
>Applications receiving an error should be able to cope with
>any unexpected error code. The EISDIR code would seem a logical
>return.
|