A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=1798 
====================================================================== 
Reported By:                eblake
Assigned To:                
====================================================================== 
Project:                    Issue 8 drafts
Issue ID:                   1798
Category:                   System Interfaces
Type:                       Clarification Requested
Severity:                   Objection
Priority:                   normal
Status:                     New
Name:                       Eric Blake 
Organization:               Red Hat 
User Reference:             ebb.posix_getdents 
Section:                    XSH posix_getdents 
Page Number:                1567 
Line Number:                52609 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2024-01-22 15:13 UTC
Last Modified:              2024-02-16 10:18 UTC
====================================================================== 
Summary:                    Must posix_getdents remember file offsets across
exec?
====================================================================== 

---------------------------------------------------------------------- 
 (0006658) corinna_vinschen (reporter) - 2024-02-16 10:18
 https://austingroupbugs.net/view.php?id=1798#c6658 
---------------------------------------------------------------------- 
>From Cygwin's side, the problem is this:

The underlying non-POSIXy kernel does not allow lseek(2) operations on
directory descriptors, not even requesting a position within the
directory.
The only available seek-like operation is equivalent to lseek(dirfd,
SEEK_SET, 0).

Therefore we have to use a DIR* and the entire operation of position
bookkeeping is performed in user space.

If the standard strives to allow implementing posix_getdents() using DIR*
under the hood, the standard should be clear on the subject that DIR is
not dup(2)'able the same way as the dir descriptor given as argument to
posix_getdents().

DIR is, by and large, a user-space object while the descriptor is a kernel
object.  DIR has never been meant as a dup'able object and there's no
precedent for such a functionality.

As such, there's no way to keep the dup'ed DIR* in sync after such a
duplication.

The same problem occurs with fork(2), which is just a more thorough dup(2)
in terms of descriptors.  

Bottom line is, with user-space DIR* with enforced user space bookkeeping,
there's no way after dup(2)/fork(2) to keep the directory position info
in sync.

Consequentially, there should be no assumption made how posix_getdents()
behaves after dup(2) or fork(2). I.e. using the descriptors with
posix_getdents() or readdir() in parallel should be undefined behaviour.


If you're interested in code, I invite you to take a look into the
current,
preliminary implementation of posix_getdents() in Cygwin:

https://cygwin.com/cgit/newlib-cygwin/commit/?id=62ca95721a14

As the commit outlines, the code does not try to keep track of the hidden
DIR at all.


Thanks,
Corinna 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2024-01-22 15:13 eblake         New Issue                                    
2024-01-22 15:13 eblake         Name                      => Eric Blake      
2024-01-22 15:13 eblake         Organization              => Red Hat         
2024-01-22 15:13 eblake         User Reference            => ebb.posix_getdents
2024-01-22 15:13 eblake         Section                   => XSH posix_getdents
2024-01-22 15:13 eblake         Page Number               => 1567            
2024-01-22 15:13 eblake         Line Number               => 52609           
2024-01-22 15:30 eblake         Note Added: 0006632                          
2024-01-22 15:39 eblake         Note Edited: 0006632                         
2024-02-16 10:18 corinna_vinschenNote Added: 0006658                          
======================================================================


  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
      • Re:... Eric Blake via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
      • Re:... Corinna Vinschen via austin-group-l at The Open Group
        • ... Corinna Vinschen via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
      • Re:... Steffen Nurpmeso via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
      • Re:... Steffen Nurpmeso via austin-group-l at The Open Group

Reply via email to