Date: Thu, 6 Feb 2003 08:35:57 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Implementation of fchmod [PATCH]
In-Reply-To: <E18gB6p-0000qr-00@phekda.freeserve.co.uk>
Message-ID: <Pine.SUN.3.91.1030206081714.6656L-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Tue, 4 Feb 2003, Richard Dawe wrote:

> Below is an implementation of fchmod. It uses fd_props to get
> the filename for the file descriptor, so that we can use chmod
> on the file.

Thanks.  However, I think this requires a bit more thinking.

First, does this really work?  I presume that you've actually run the 
test program, but I still wonder: does it work on DOS and Windows 
(including on the NT family) to change the file's read/write permissions 
while it is open?  What happens if I open a file, write something to it, 
then change its mode to be read-only, and then try to write some more?

Also, do we always have the file's name in fd_props?  What happens with 
calls to _open and its low-level friends like _creat?  What happens with 
inherited handles, like the 5 standard ones?  If this function doesn't 
work for them, we should at least document that (see below).

And I don't think ENOENT is correct for when fd_props don't give us the 
name.  This is a valid handle (we validated it before), so we should at 
least try to see if we are dealing with a device (in which case we could 
probably simply silently ignore the request, or maybe fail and set errno 
to ENOSYS).

Finally, there is an LFN function to get file's attributes given its 
handle (Int 21h/AX=71A6h).  Perhaps we should use it to see if the file 
is already set to what's required, and never fail in that case.  
(I'm thinking about possible failures of fd_props, like if the file was 
opened with direct __dpmi_int calls, or its handle was inherited from the 
parent process.)

> + This function changes the mode (writable or write-only) of the file
> + opened under the file descriptor @var{fd}.  The value of @var{mode}
> + can be a combination of one or more of the following:
> + 
> + @table @code
> + 
> + @item S_IRUSR
> + 
> + Make the file readable
> + 
> + @item S_IWUSR
> + 
> + Make the file writable
> + 
> + @end table
> + 
> + Other @code{S_I*} values could be included, but they will be ignored
> + for regular files.

I suggest to make this description more detailed.  First, I think you 
should list _all_ the S_I* values, or at least have a cross-reference to 
a place in the manual where they are all listed.  Second, the text 
doesn't say what happens for character devices.  Third, S_IRUSR is also 
ignored, since a file is always readable on DOS/Windows.