The trick in this case is trying to determine whether the deviation from
the standard reveals a shortfall in the standard- the vendor is fixing
something which was wrong in the standard or covering a case which was
simply not anticipated when the standard was written. Neither vendors nor
standards organizations are infallable. That's what technical review
committees exist for- to reconcile the inevitable discrepency between
standard and reality.
I agree that the current practice of returning EISDIR does not indicate,
by itself, a need to change. However, it is not an irrelevent fact. By and
large, we want the standard to be (slowly) moving in the direction of
providing a better interface and supporting better programming practices.
From a programming perspective (without consideration to standards), the
use of EISDIR makes much more sense. The difference between a permissions
problem and a limitation of the filesystem implementation is significant.
Taken from the side of application portability, again without
consideration of standards, I have two different problems: 1) I have to
deal with an EISDIR return on some platforms which may break my code and
2) I can't find enough information on some platforms about why my call
failed. Loosening the standard to allow EISDIR here makes #1 worse, while
tightening it to clearly dissallow EISDIR makes #2 worse. However, merely
loosening the standard doesn't help make #2 *better* unless it is coupled
with a clear statement of intent and direction.
Therefore, when it comes down to considering standards conformance we
really have two options:
1) Leave the standard disallowing EISDIR, possibly tightening the wording
and cracking down on non-conformant systems (which claim conformance).
Customers may wish to place additional pressure on systems which do not
claim conformance but which intend to be compatible (e.g. Linux).
2) Loosen the standard to allow EISDIR returns *and* tighten the standard
by stating that EPERM will be dissallowed in the future. If EISDIR is
really the better path and if significant implementations will go that way
regardless of whether the standard does, it makes my portability problems
no worse and promises to make them better.
I don't think we have any business allowing EISDIR without making a
statement that EPERM will not be allowed, given a suitable transition
period. In that case, we are just being wishy-washy and making
portability harder.
On Wed, 10 Apr 2002, Donn Terry wrote:
> When the standard was originally being written, there were a few places
> where
> more than one error condition was permitted for the same problem, and
> there were
> other adaptations to the existing practice of the time.
>
> Systems that deviate from the standard that came to exist after the
> standard was
> published (including, assuredly, "my own") have no excuse not to conform
> to the
> standard as written, if they choose to claim conformance. If we don't
> hold a
> bright line on this, the standard will have no purpose: if every time
> someone
> "invents" or "goofs" and doesn't follow the standard, and we allow that,
> then
> the standard will cease to provide what it exists for: application
> portability.
>
> "Standard is better than better." -- Portia Isaacson. (sp?)
>
> Donn
>
> -----Original Message-----
> From: yyyyyyyyyyyyyyy@xxxxxx [mailto:yyyyyyyyyyyyyyy@xxxxxx]
> Sent: Wednesday, April 10, 2002 10:46 AM
> To: yyyyyy@xxxxxxxxxxxxx; yyyyyyyyyyyyyyy@xxxxxxxxxxxxx;
> yyy@xxxxxxxxxxxxxxxxxxx
> Subject: Re: Defect in XSH unlink
>
>
> 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.
>
> 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.
>
> Things depend on your definition of POSIX system.
> There are lots of minor differences between almost any Unix-like system
> and the POSIX standard. Certainly 4.3BSD that you quote does not fully
> conform to POSIX.
>
> These days we also have Linux as an important example of a Unix-like
> system. I don't know whether Andrew's question was inspired by it, but
> Linux returns EPERM in case 1, and EISDIR in case 2.
>
> So "it is too late to rewrite history" does not really apply. History
> was rewritten already. Every portable application will today have to
> reckon with the possibility of an EISDIR return.
>
> Andries
>
>
--
Eric Vought
Chief Technical Officer - QLUE Consulting, Inc.
yyyyyyy@xxxxxxxx toll-free: 888-771-3538 RTP area: 919-816-9901
|