On Tue, Sep 1, 2020 at 6:22 AM Steffen Nurpmeso via austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote:
> Robert Elz via austin-group-l at The Open Group wrote in > <9252.1598969...@jinx.noi.kre.to>: > | Date: Tue, 1 Sep 2020 10:32:55 +0100 > | From: "Geoff Clare via austin-group-l at The Open Group" \ > | <austin-group-l@opengroup.org> > | Message-ID: <20200901093255.GA7629@localhost> > ... > |What's more important is what happens if the application buffer isn't > |big enough for the next entry. What do the existing getdents() > |implementations do in that case? If they're all the same then > |posix_getdent() should do the same thing (EINVAL? E2BIG?) - if they > |differ, then we can decide what's best. > > Isn't that covered nicely by the posted text? There must be space > for at least one entry, otherwise EINVAL occurs? And upon success > "a non-negative integer shall be returned indicating the number of > bytes occupied by the <b>posix_dent</b> structures placed in > <i>buf</i>", which even for a non-native tongue implies that there > may be pad left. I think you are overcomplicating here. > A quick review of FreeBSD, NetBSD, and OpenBSD finds they all return EINVAL if the buffer isn't "big enough". For OpenBSD, the minimum buffer size is 512 bytes; if I'm reading it correctly NetBSD is similar, possibly varying based on filesystem formatting. FreeBSD requires space for the next entry. |Similarly for what is done for directory pieces that don't contain > |files, on filesystems that allow that (inode number == 0 or perhaps > |a file type for "dummy entry" or something, or whatever). > > I personally would say that these should be skipped. The data is > copied over to user buffers, and these entries are simply not > copied. That seems to be the best. The Group does not seem to > want to add DT_WHITEOUT or similar things. > DT_WHITEOUT is different, related to union mounts. |Do the existing implementations ever return such things? Do they > > I personally have not seen it, but this likely is a very > filesystem dependent thing, which possibly even changes over time At least NetBSD and OpenBSD will return an entry with d_ino == 0 if the first entry in a block is removed. I suspect others may do this as well; glibc at least includes code to skip such entries in its generic readdir() implementation. The question really is "is this supposed to be a API that can be trivially supported by all the existing versions, even if that makes it more clunky to use, or should it be easy to use even if every single existing implementation needs to bend?" If the former, then define a minimum buffer size (pathconf(_PC_DIRBUFMIN)...?), permit d_ino==0 as entries where d_name and d_type are unspecified, and let d_name be either a fixed fix array or a flexible array member. If the latter, then require it to work with very small buffers, require all entries to have valid d_name and d_type, and specify d_name as a FAM. Philip Guenther
