Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E5C1B27.47B225B@phekda.freeserve.co.uk>
Date: Wed, 26 Feb 2003 01:40:55 +0000
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: DJGPP workers <djgpp-workers AT delorie DOT com>
Subject: Re: Implementation of fchmod [PATCH]
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1030206081714 DOT 6656L-100000 AT is> <3E54E663 DOT 5F32DFF7 AT phekda DOT freeserve DOT co DOT uk> <2427-Sat22Feb2003220304+0200-eliz AT is DOT elta DOT co DOT il> <3E5B6452 DOT 82F4D938 AT phekda DOT freeserve DOT co DOT uk> <7263-Tue25Feb2003211713+0200-eliz AT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> > Date: Tue, 25 Feb 2003 12:40:50 +0000
> > From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
> >
> > FWIW Linux allows writes to the file, after fchmod'ing to be read-only.
> > The test program at the end of this mail works fine on Linux. The file
> > is read-only afterwards.
> 
> Then there's no problem, I think.  Thanks for looking into this.

You're welcome. It's nice to see DOS works like Linux sometimes (or
vice-versa!).

> > I thought about returning ENOSYS instead of ENOENT. I think you suggested
> > this before. But this would be misleading, I think. I take ENOSYS to mean
> > that the system call is not implemented at all, whereas we've partially
> > implemented it. So I think ENOENT is right.
> 
> ENOSYS means the feature is not supported, so I think it's okay.  I
> won't mind to use ENOENT, but please consider what will a user think
> when presented with "No such file or directory" in response to a
> function that didn't accept any file name.

I agree ENOSYS makes more sense from a user's perspective. I'll change the
code.

I also wonder how many people will actually check fchmod's return code...

> > But how do we detect that standard handles are piped?
> 
> Call isatty on the handle; if it returns zero, the handle is
> redirected.

But can we assume file descriptors 0, 1, etc. are actually standard handles?
What happens if the program closes them and then opens some other file? I
don't think we can reliably tell whether it's a standard handle. So we can't
return the pipe-specific error.

Thanks, bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]