Mail Archives: djgpp-workers/2003/02/20/09:59:30
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/ ]
- Raw text -