Mail Archives: djgpp-workers/2003/03/04/14:40:24
> 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.
> 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.
> 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.
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.
> 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.
> __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.
> ISSUE: Do we want to support the O_DIRECTORY option that Linux does?
Why not?
> 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.
Last, but not least: thanks for working on this.
- Raw text -