On Mittwoch, 24. November 2021 16:45:30 CET Michael Roitzsch wrote:
> Hi,
>
> > Are you sure d_seekoff doesn't work on macOS?
>
> I just tried on an APFS volume on macOS Monterey and d_seekoff is always 0,
> while telldir() outputs useful values.
> > Because using telldir() instead
> > is not the same thing. Accessing d_*off is just POD access, whereas
> > telldir() is a syscall.
>
> I am not sure this is the case. I have tried a quick test program:
>
> #include <dirent.h>
>
> int main(void)
> {
> int result = 0;
> DIR *dir = opendir(".");
> while (readdir(dir)) {
> result += telldir(dir);
> }
> closedir(dir);
> return result;
> }
>
> I ran it with 'sudo dtruss ./test', which should give me a trace of the
> system calls. The relevant portion is:
>
> open_nocancel(".\0", 0x1100004, 0x0) = 3 0
> sysctlbyname(kern.secure_kernel, 0x12, 0x7FF7BE49810C, 0x7FF7BE498110,
> 0x0) = 0 0 fstatfs64(0x3, 0x7FF7BE498110, 0x0) = 0 0
> getdirentries64(0x3, 0x7FF4A5808A00, 0x2000) = 1472 0
> close_nocancel(0x3) = 0 0
>
> The directory has more than 30 entries, but the loop does not appear to
> cause individual system calls. Instead, readdir() and telldir() appear to
> be library functions powered by this getdirentries64 syscall.
Right, telldir() is part of Apple's libc, no (fs) syscall involved:
https://opensource.apple.com/source/Libc/Libc-167/gen.subproj/telldir.c.auto.html
However instead of changing the (fs driver independent) 9p server [9p.c] code
and using fidp there, I would probably rather address this issue for macOS in
the individual fs drivers [9p-local.c, 9p-synth.c, 9p-proxy.c] directly on
dirent instead, and not rely on fidp not having mutated on server.
And please make sure the 9p test cases pass.
Best regards,
Christian Schoenebeck
