How about allowing it as an either or case. We do this in several
cases elsewhere in the specification. Are applications relying
on the particular error case and would they broken by opening
it up?
regards
Andrew
On Apr 10, 9:56am in "Re: Defect in XSH un", Don Cragun wrote:
> 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.
>-- End of excerpt from Don Cragun
-----
Andrew Josey The Open Group
Austin Group Chair Apex Plaza,Forbury Road,
Email: yyyyyyy@xxxxxxxxxxxxx Reading,Berks.RG1 1AX,England
Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110
|