A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=697 
====================================================================== 
Reported By:                steffen
Assigned To:                
====================================================================== 
Project:                    1003.1(2013)/Issue7+TC1
Issue ID:                   697
Category:                   System Interfaces
Type:                       Clarification Requested
Severity:                   Comment
Priority:                   normal
Status:                     New
Name:                       Steffen Nurpmeso 
Organization:                
User Reference:              
Section:                    none 
Page Number:                none 
Line Number:                none 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2013-05-15 10:31 UTC
Last Modified:              2020-08-30 23:06 UTC
====================================================================== 
Summary:                    Adding of a getdirentries() function
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0000696 either NAME_MAX shouldn't be optional, ...
====================================================================== 

---------------------------------------------------------------------- 
 (0004958) philip-guenther (reporter) - 2020-08-30 23:06
 https://austingroupbugs.net/view.php?id=697#c4958 
---------------------------------------------------------------------- 
The proposed text includes:
    The d_name member shall be a filename string, and (if not dot or
dot-dot)
    shall contain the same byte sequence as the last pathname component of
the
    string used to create the directory entry, plus the terminating <NUL>
byte.

That would seem to require that all returned entries correspond to
filenames that existed in the directory at _some_ point in time.  However,
I see no requirement that posix_getdents() only return currently existing
files, nor any requirement that non-existing files be flagged in any way. 
The former at least seems like an oversight that should be corrected.

I interpret the definition of readdir(), including its description of the
DIR type:
    The type DIR, which is defined in the <dirent.h> header, represents a
    directory stream, which is an ordered sequence of all the directory
    entries in a particular directory.
and later text as effectively requiring that readdir() may not return an
entry for a file that did not exist at some point between when opendir() or
rewinddir() was last called and when readdir() returned it.

Since posix_getdents() is all about bulk transfer with no buffering, I
think its description should be updated EITHER to require that
a) all returned entries must have existed at some point during the call,
OR
b) all returned entries with d_ino != 0 must have existed at some point
during
   the call and specify that entries with d_ino == 0 may have d_name[0] ==
'\0'

Specifying (b) is more in line with historical BSD behavior, but does
require additional application logic, so I'm sympathetic to a view that
specifying (a) is the cleaner choice. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2013-05-15 10:31 steffen        New Issue                                    
2013-05-15 10:31 steffen        Name                      => Steffen Nurpmeso
2013-05-15 10:31 steffen        Section                   => none            
2013-05-15 10:31 steffen        Page Number               => none            
2013-05-15 10:31 steffen        Line Number               => none            
2013-05-15 22:08 jilles         Note Added: 0001607                          
2013-05-16 10:22 steffen        Note Added: 0001608                          
2013-05-30 15:37 eblake         Relationship added       related to 0000696  
2013-05-30 15:57 geoffclare     Note Added: 0001629                          
2014-03-30 00:33 sstewartgallus Issue Monitored: sstewartgallus                 
  
2020-08-28 08:21 geoffclare     Note Added: 0004947                          
2020-08-28 08:27 geoffclare     Note Edited: 0004947                         
2020-08-28 17:07 shware_systems Note Added: 0004948                          
2020-08-28 17:52 kre            Note Added: 0004949                          
2020-08-28 22:42 philip-guentherNote Added: 0004952                          
2020-08-28 22:52 philip-guentherNote Added: 0004953                          
2020-08-29 11:34 shware_systems Note Added: 0004955                          
2020-08-29 11:34 shware_systems Note Added: 0004956                          
2020-08-29 11:41 shware_systems Note Edited: 0004956                         
2020-08-29 11:44 shware_systems Note Deleted: 0004955                        
2020-08-29 13:07 shware_systems Note Added: 0004957                          
2020-08-29 13:11 shware_systems Note Edited: 0004957                         
2020-08-30 23:06 philip-guentherNote Added: 0004958                          
======================================================================


  • [1003.1(2013... Austin Group Bug Tracker via austin-group-l at The Open Group
    • Re: [10... Per Mildner via austin-group-l at The Open Group
      • Re:... Geoff Clare via austin-group-l at The Open Group
      • Re:... Robert Elz via austin-group-l at The Open Group
        • ... Steffen Nurpmeso via austin-group-l at The Open Group
          • ... Philip Guenther via austin-group-l at The Open Group
            • ... Steffen Nurpmeso via austin-group-l at The Open Group
              • ... Philip Guenther via austin-group-l at The Open Group
  • [1003.1(2013... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2013... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2013... Austin Group Bug Tracker via austin-group-l at The Open Group
    • Re: [10... Geoff Clare via austin-group-l at The Open Group
      • Re:... Philip Guenther via austin-group-l at The Open Group
        • ... Geoff Clare via austin-group-l at The Open Group
  • [1003.1(2013... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2013... Austin Group Bug Tracker via austin-group-l at The Open Group
  • Re: [1003.1(... shwaresyst via austin-group-l at The Open Group
    • Re: [10... Geoff Clare via austin-group-l at The Open Group
    • RE: [10... Wojtek Lerch via austin-group-l at The Open Group
  • Re: [1003.1(... shwaresyst via austin-group-l at The Open Group
    • Re: [10... Steffen Nurpmeso via austin-group-l at The Open Group

Reply via email to