nlink discrepancy

[mcandre]

tar tzvf reports different hard link data for Xcode pkgbuild generated Payload gzip streams, versus cpio-archive generated streams.

pkgbuild:

% tar tzvf Payload
drwxr-xr-x  3 0      0           0 Jan 27 16:43 .
drwxr-xr-x  3 0      0           0 Jan 27 16:43 ./bin
-rwxr-xr-x  1 0      0          31 Jan 27 15:03 ./bin/hello
-rw-r--r--  1 0      0         163 Jan 27 15:03 ./bin/._hello
-rw-r--r--  3 0      0         163 Jan 27 16:43 ./._bin

cpio-archive:

% tar tzvf Payload
drwxr-xr-x  0 0      0           0 Jan 27 17:22 .
drwxr-xr-x  0 0      0           0 Jan 27 17:22 ./bin
-rwxr-xr-x  0 0      0          31 Jan 27 17:22 ./bin/hello

Note the second column. Online research suggests this column tracks the number of hard links. Isn't that the nlink field in cpio-archive headers?

Neither regular files, nor (auto generated) directories appear to be populating this field correctly.

The algorithm for the number calculation seems somewhat straightfoward: 1 + the number of direct child entries (for directories). However, as ./._bin is not a real directory, it takes the same value as its ./bin source. As long as our CPIO archive doesn't gain any AppleDouble entries, we needn't worry about that caveat.