[tz] macOS implements Links with file copies?

[Emily Crandall Fleischman]

It looks like Catalina (10.15.7) uses hard links:

$ ls -li /usr/share/zoneinfo.default/US/Pacific
/usr/share/zoneinfo.default/America/Los_Angeles
1152921500311900283 -rw-r--r--  3 root  wheel  2819 Nov  9  2019
/usr/share/zoneinfo.default/America/Los_Angeles
1152921500311900283 -rw-r--r--  3 root  wheel  2819 Nov  9  2019
/usr/share/zoneinfo.default/US/Pacific



On Fri, 12 Feb 2021 at 15:49, Paul Eggert <eggert at cs.ucla.edu> wrote:
>
> [Subject line retitled from "[tz] "official" zone name alternatives via
> Link records'.]
>
> On 2/12/21 11:31 AM, Paul Gilmartin via tz wrote:
> > the MacOS distribution (at Mojave) contains no
> > symlinks; the files are entirely replicated.
>
> Yes, unfortunately this sort of problem seems to be relatively common.
> Fedora and Solaris use hard links:
>
> $ ls -li /usr/share/zoneinfo/America/Los_Angeles
> /usr/share/zoneinfo/US/Pacific
> 2111636 -rw-r--r--. 2 root root 2836 Jan 25 19:02
> /usr/share/zoneinfo/America/Los_Angeles
> 2111636 -rw-r--r--. 2 root root 2836 Jan 25 19:02
> /usr/share/zoneinfo/US/Pacific
>
> whereas Ubuntu (and I assume Debian) use less-efficient symbolic links:
>
> $ ls -li /usr/share/zoneinfo/America/Los_Angeles
> /usr/share/zoneinfo/US/Pacific
> 1182409 -rw-r--r-- 1 root root 2836 Jan 27 11:53
> /usr/share/zoneinfo/America/Los_Angeles
> 1206418 lrwxrwxrwx 1 root root   22 Jan 27 11:53
> /usr/share/zoneinfo/US/Pacific -> ../America/Los_Angeles
>
> and macOS uses copies, although I don't know whether these are true
> copies (which would be even less efficient than symlinks), or are merely
> APFS copy-on-write clones (not so bad).
>
> The hard-link approach is zic's original approach, and zic still uses
> hard links unless the filesystem does not support hard links (or in the
> rare case where -l or -p is used and the destination exists and is
> already a symlink).
>
> On filesystems that support neither hard links nor symlinks, zic
> currently falls back by coping via 'read' and 'write'. zic could try
> ioctl with FICLONE (Linux) or clonefile (macOS) if available, before
> falling back on 'read' and 'write'. I don't know whether it'd be worth
> the hassle to do that, though. Partly it depends on why macOS has
> copies; if the copies are not made by zic, there's not much point to
> changing zic.