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