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 18:14 UTC
====================================================================== 
Summary:                    Must posix_getdents remember file offsets across
exec?
====================================================================== 

---------------------------------------------------------------------- 
 (0006710) geoffclare (manager) - 2024-03-07 18:14
 https://austingroupbugs.net/view.php?id=1798#c6710 
---------------------------------------------------------------------- 
> You're missing the fact that the underlying OS does *not* maintain a file
position on directory descriptors.

Actually, I think I knew that, but had forgotten it.

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.

To make it work for an lseek() on an fd obtained from dup(), as in
https://austingroupbugs.net/view.php?id=1798#c6703, 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 if a directory stream can be associated with more than one fd,
but it seems to me that this could be a promising approach that would
provide better compatibility with other systems. 

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                          
======================================================================


    • Re: [Is... Eric Blake 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... 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

Reply via email to