On Oct 5, 2025, at 8:24 PM, Jonathan Leffler <[email protected]> wrote:
> I note that the macOS (15.6) manual includes the caveat: > > The file generation number, st_gen, is only available to the super-user. > > I don't know if that applies to the *BSD releases. FreeBSD and OpenBSD appear to expose it to non-root users. NetBSD appears to return 0 - the vnode operation for a file system returns it, but vn_stat() in kern/vfs_vnops.c ignores it. I think the original intent in supporting it in the node operations was to allow *NFS servers* to access it and return ESTALE if the generation count in the file handle doesn't match the generation count of the file to which it purports to refer. I don't have access to SunOS [234].x source, so I can't check whether it let the generation number/sequence number for a file escape kernel mode, but Illumos, which is the closest thing I have to SunOS 5.x source, has va_seq as the equivalent of va_gen in vnode attributes, but does not have anything in the stat structure to export it to userland. So, on at least some *BSDs, such as NetBSD nd CupertinoBSD, will often or always return 0, although others may not. (And a quick look at the last version of the HFS+ code in CupertinoBSD doesn't show any sign that it even exports va_gen to callers from above the vnode layer; the NFS server code in the version of XNU appears to use a *separate* vnode generation-countish attribute, but only for cookies in NFSv3.) > I don't know how much of a problem that is for the proposed TZ code. At most, I think it means that, on some platforms, you won't be able to detect the case wherein a version of the TZif file in question was removed and replaced with a different one *that happened to get the same inode number as the previous one* - but the code would presumably also be checking for the modification and node-change time, which would presumably normally catch that case. I'm not sure how likely that is to be a problem for commonly-used file systems.
