Mail Archives: djgpp-workers/2003/03/04/16:14:49
Hello.
Jim: Please let me know, if you'd like to be removed from the CC list. I
thought you might like to be involved in this, just in case we do something to
the fchdir implementation that will break it for your purposes.
Eli Zaretskii wrote:
>
> > Date: Tue, 04 Mar 2003 15:12:49 +0000
> > From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
> >
> > One concern with requiring fd_props for a file descriptor is
> > that the file descriptor may be used with functions that are
> > not aware of directories, e.g.: _dos_write.
>
> See below: I don't think DOS-specific functions should support
> directory file descriptors.
OK. That makes things a lot simpler.
> > It may also be inherited -
> > the child program will have no access to fd_props. To handle these cases,
> > I suggest that the directory's file descriptor be dup'd off nul.
>
> You could disable inheritance by moving the file handles (see move_fd
> in src/debug/common/dbgredir.c for an example how to do that) above
> handle 19. File handles above 19 are not passed to the child programs
> (a misfeature of the DOS Exec call).
>
> I'm not sure we should bother about inheritance, but I thought I'd
> mention this just in case.
That sounds like a better idea. It will stop directory file descriptors from
consuming the inheritable file descriptors.
> > The file mode should also be set to binary. We could use __FSEXT_alloc_fd
> > to do this.
>
> I'm concerned by increasing use of FSEXT in the library itself. I
> think FSEXT is a user-level feature, and thus the library should not
> use it, for fear of conflicts. Remember: FSEXT does not have any
> provisions to control the order in which the extensions are invoked.
I wasn't suggesting that we use the FSEXT mechanism to support directory file
descriptors. I don't think FSEXT is the right way to go either.
__FSEXT_alloc_fd appeared to do the right thing in terms of allocating a file
descriptor:
* dup'ing nul;
* setting the mode to binary.
So we could use __FSEXT_alloc_fd for convenience. __opendir_as_fd() could do
something like this:
int
__opendir_as_fd (const char *filename, const int oflags)
{
int fd;
/* Handle bogus oflags like O_RDWR, O_APPEND. */
fd = __FSEXT_alloc_fd();
/* Handle errors */
__set_fd_flags(fd, FILE_DESC_DIRECTORY);
return(fd);
}
Clearly if we're going to ensure that the file descriptor is > 19, then we
can't use __FSEXT_alloc_fd.
> Since in this case, only Posix functions need to support directory
> handles, there's a contradiction with FSEXT machinery which works at
> the (lower) DOS interface level.
>
> So I suggest to implement this feature as add-on code inside Posix
> functions such as open, read, etc. I don't think we should push it
> down to _open, _read, etc., and neither should we support such handles
> below the Posix layer.
OK.
> > open
> > ----
> >
> > src/libc/posix/fcntl/open.c
> > src/dos/io/_creat.c
> > src/dos/io/_creat_n.c
> > src/dos/io/_open.c
> >
> > I suggest that directories are handled first as a special case
> > in open. If the filename refers to a directory (check with
> > access(..., D_OK), open would call this function, say __opendir_as_fd,
> > and then return its return code.
>
> Please be sure to call `access' _only_ if `_open' failed. Otherwise,
> we are going to add unneeded overhead to the normal file case.
OK, that seems like a good idea.
> > __opendir_as_fd would:
> >
> > * call the FSEXT handler with __FSEXT_open, to allow hooking,
> > then return appropriately, if the FSEXT handled it;
>
> I don't think we need to support FSEXT handlers for this. If you
> think otherwise, please tell why.
Since _open calls the FSEXT handlers, they will have a chance to hook this.
But I see your point: we don't support FSEXTs for directory-related functions.
> > ISSUE: Do we want to support the O_DIRECTORY option that Linux does?
>
> Why not?
It's a Linux-specific extension. Because it's not POSIX. Because if we provide
it, people might start using it. They can check whether the directory exists
beforehand using access or stat.
> > We can handle both write and _write, by adding a check to _write,
> > after the FSEXT handler has been called. It would try to find the flags
> > for the file descriptor by using __get_fd_flags. If it can
> > and the file descriptor refers to a directory, it would fail with
> > errno == EACCES.
> >
> > NOTE: POSIX seems a bit unclear here to me. It says that the errno == EBADF
> > should be used when "The fildes argument is not a valid file descriptor
> > open for writing." This covers two error conditions: invalid file
> > descriptor; file descriptor not open for writing. So I'm not sure that
> > errno == EACCES is correct above.
>
> EACCES is returned by too many DJGPP system calls (because DOS forces
> us to do that). So it would be good to avoid EACCES if some other
> code is equally appropriate.
OK. Maybe we should go for EBADF.
> Last, but not least: thanks for working on this.
It's just another step along the way to POSIX compliance...
Thanks for the feedback!
Thanks, bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -