Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <3E651688.D712D4A9@phekda.freeserve.co.uk> Date: Tue, 04 Mar 2003 21:11:36 +0000 From: Richard Dawe 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 CC: djgpp-workers AT delorie DOT com, jim AT meyering DOT net Subject: Re: Design for fchdir References: <3E64C271 DOT 556CBDF2 AT phekda DOT freeserve DOT co DOT uk> <9003-Tue04Mar2003213527+0200-eliz AT elta DOT co DOT il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com 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 > > > > 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/ ]