On Tue, Sep 1, 2020 at 5:40 AM Geoff Clare via austin-group-l at The Open
Group <[email protected]> wrote:

> > ----------------------------------------------------------------------
> >  (0004958) philip-guenther (reporter) - 2020-08-30 23:06
> >  https://austingroupbugs.net/view.php?id=6
> <https://austingroupbugs.net/view.php?id=697#c4958>


-- 
Geoff Clare <[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

> 97#c4958 <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.
>
> It is just copied from existing text for readdir() in Issue 8 draft 1.
> See bug 293.
>

That part is fine, that the returned names match the creation names.  My
concern in that comment is that there's no requirement on posix_getdents()
to only return _currently_ existing names.

If a posix_getdents() implementation returned the names of all the files
that ever existed in the given directory, including ones that were removed
before the fd for this call was opened, what requirement in the standard
would that violate?  I don't see any, thus my suggested wording for such a
requirement.

Philip
      • 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
  • RE: [1003.1(... shwaresyst via austin-group-l at The Open Group
    • RE: [10... Wojtek Lerch via austin-group-l at The Open Group

Reply via email to