Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <3E54E663.5F32DFF7@phekda.freeserve.co.uk> Date: Thu, 20 Feb 2003 14:29:55 +0000 From: Richard Dawe X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586) X-Accept-Language: de,fr MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp-workers AT delorie DOT com Subject: Re: Implementation of fchmod [PATCH] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Hello. Eli Zaretskii wrote: > > 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? Yes, it works under Windows '98 SE. > 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? It seems like DOS boxes under Windows (the LFN API, at least) have a separate concept of open mode and attributes. So you can create a file that is read-only, but open it in read-write mode at creation time. See the recent discussion about _creatnew. The attributes seem to apply to opens after that point. It seems like you can change the file attributes from, say, read-write to read-only on a file that was opened for read-write and still write to it: open for read-write write to file change attributes to read-only write to file close file None of this fails on Windows '98 SE. I suspect it will fail under DOS, where the LFN API is not present and there is no extended create call. I have not done any testing yet. > 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). I think we should either silently ignore the request for devices or return -1 and errno == EPERM. By "device" I presume you mean "character device" (bit 7 set in the attributes). > 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.) That sounds like a good idea. Here's what I've implemented so far: let fsext handle it, if it wants if it's a character device, ignore the request and return success try to find out current permissions - if they match the requested ones, just return if no filename is known from fd_props, fail with errno == ENOENT otherwise do a chmod on the filename This works for the standard handles, unless there is redirection. If there is redirection, it will fail unless the requested permissions match those of the source/destination file of the redirection. > > + 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. OK. Thanks, bye, Rich =] -- Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]