[tz] macOS implements Links with file copies?

[Paul Eggert]

[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.