Philip Guenther wrote in <cakkmsnhee-umta17hut19dqttnj-tm3aqpngimk-bplehq_...@mail.gmail.com>: |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 .. |> 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 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.
They document that "the size must be greater than or equal to the block size associated with the file", but i cannot find this "next entry" of yours? ||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. 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. Yes. I think it was mentioned in the tracker discussion. ||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?" But .. it is already supported by all, and it has always been used?! And i like this forward-looking approach that has been taken by the group, having that stat(2) call removed is fine. (Even though that is easily doable with the current standard and fstatat(), which is a totally different situation to twenty years ago! Yay!) |If the former, then define a minimum buffer size |(pathconf(_PC_DIRBUFMIN)...?), permit d_ino==0 as entries where d_name and However there is _PC_NAME_MAX already, and so the number must be nearby, no? Isn't that overengineering? |d_type are unspecified, and let d_name be either a fixed fix array or a |flexible array member. You know, my personal position would be to just skip those entries when copying data over to user buffers. The costs of walking over the user buffer once (if it is done like that, and that memory should be hot even, then) seem to be low compared to collecting the directory entry information. |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. That d_type from the start would be great. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
