Mail Archives: djgpp-workers/2003/02/20/09:59:30

Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <>
Date: Thu, 20 Feb 2003 14:29: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: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: 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>
Reply-To: djgpp-workers AT delorie DOT com


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

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.


Thanks, bye, Rich =]

Richard Dawe [ ]

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019