Date: Tue, 04 Mar 2003 21:35:27 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: rich AT phekda DOT freeserve DOT co DOT uk Message-Id: <9003-Tue04Mar2003213527+0200-eliz@elta.co.il> X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 CC: djgpp-workers AT delorie DOT com, jim AT meyering DOT net In-reply-to: <3E64C271.556CBDF2@phekda.freeserve.co.uk> (message from Richard Dawe on Tue, 04 Mar 2003 15:12:49 +0000) Subject: Re: Design for fchdir References: <3E64C271 DOT 556CBDF2 AT phekda DOT freeserve DOT co DOT uk> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Tue, 04 Mar 2003 15:12:49 +0000 > From: Richard Dawe > > 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.