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:                     Resolution Proposed
Name:                       Eric Blake 
Organization:               Red Hat 
User Reference:             ebb.posix_getdents 
Section:                    XSH posix_getdents 
Page Number:                1567 
Line Number:                52609 
Final Accepted Text:        https://austingroupbugs.net/view.php?id=1798#c6695 
====================================================================== 
Date Submitted:             2024-01-22 15:13 UTC
Last Modified:              2024-03-07 20:24 UTC
====================================================================== 
Summary:                    Must posix_getdents remember file offsets across
exec?
====================================================================== 

---------------------------------------------------------------------- 
 (0006711) corinna_vinschen (reporter) - 2024-03-07 20:24
 https://austingroupbugs.net/view.php?id=1798#c6711 
---------------------------------------------------------------------- 
> So the Cygwin lseek() must have to fake an offset for fds associated with
a
> directory stream - presumably returning the read count - and accept
those
> faked offsets as input

Yes, as I described in my previous note, readdir() keeps count, telldir()
returns the count, seekdir () rewinds and calls readdir until the count
equals
the seekdir() argument.

lseek() on dirs was not implemented at all due to the OS not supporting
it.

lseek() is now supported for dirs used in posix_getdents() by calling
telldir()/seekdir() under the hood, see

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

> To make it work for an lseek() on an fd obtained from dup(), as in
> Note: 0006703, couldn't you have dup() notice that the fd passed in is
> associated with a directory stream and create an association between
> the new fd and the same directory stream? Admittedly the code would be
> more complicated

Actually a *lot* more complicated.

You're basically now expecting shared bookkeeping of DIRs.

But this was never before required by opendir()/readdir()/...

A DIR is an allocated user space structure on the heap.  The only way
of sharing a DIR was by duplicating it via fork(). The two resulting
DIRs in the parent and child processes are disconnected and they function
independently of each other.

If you now require DIRs to be shared across dup() and fork(), you're
basically requiring a rewrite of otherwise conforming implementations
of opendir() and friends.  It would require to store a DIR in shared
memory, add interprocess locking to readdir() , and whatnot.

If the idea was to allow implementing posix_getdents() with existing
DIR under the hood, this new requirement breaks this assumption, just
for a border case.


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                          
2024-02-29 17:27 geoffclare     Note Added: 0006695                          
2024-02-29 17:29 geoffclare     Final Accepted Text       =>
https://austingroupbugs.net/view.php?id=1798#c6695    
2024-02-29 17:29 geoffclare     Status                   New => Resolution
Proposed
2024-02-29 17:29 geoffclare     Resolution               Open => Accepted As
Marked
2024-02-29 17:30 geoffclare     Tag Attached: tc1-2024                       
2024-03-04 09:38 corinna_vinschenNote Added: 0006703                          
2024-03-07 12:28 geoffclare     Note Added: 0006708                          
2024-03-07 15:00 corinna_vinschenNote Added: 0006709                          
2024-03-07 18:14 geoffclare     Note Added: 0006710                          
2024-03-07 20:24 corinna_vinschenNote Added: 0006711                          
======================================================================


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

Reply via email to