On Jun 27, 2024, at 2:47 AM, Leah Neukirchen <leah(a)vuxu.org> wrote: This is a bit tricky. Linux doesn't add ' link to b' so you don't know what c is linked to. If you want to show this info using any printable char, you get in trouble as a file of the same name can be made! Tar is a bit better: $ touch a; ln a b; touch 'b link to a'; ln 'b link to a' c $ ls | tar -cI - | tar -tv -rw-r--r-- 0 bakul wheel 58 Jun 27 14:50 a hrw-r--r-- 0 bakul wheel 0 Jun 27 14:50 b link to a -rw-r--r-- 0 bakul wheel 0 Jun 27 14:39 b link to a hrw-r--r-- 0 bakul wheel 0 Jun 27 14:39 c link to b link to a That 'h' in this first column tells you this is a hard link. Not so with cpio! $ ls | cpio -o | cpio -ivt 2 blocks -rw-r--r-- 2 bakul wheel 58 Jun 27 14:50 a -rw-r--r-- 2 bakul wheel 58 Jun 27 14:50 b link to a -rw-r--r-- 2 bakul wheel 0 Jun 27 14:39 b link to a -rw-r--r-- 2 bakul wheel 0 Jun 27 14:39 c link to b link to a I think at the very least this extra info should be displayed using another flag. This feels more like a half done job. tar doesn't duplicate the data so the extraction fails. cpio duplicates the data so fixing the bug would be easy. It is not at all clear what is the right choice (re whether to duplicate the data or not), especially if I have a very large file with multiple hard links. I tend to think *not* duplicating the data is the right choice as you can always re-run tar x and extract the original as well as the hard linked name. But you may think differently. In any case, the original culprit is libarchive (on FreeBSD) as Leah pointed out, not OSX! What is more, dealing with hardlinks & copying has always been troublesome.

On Thu, Jun 27, 2024 at 8:02 AM Peter Yardley <peter.martin.yardley(a)gmail.com> wrote: Not true! It does: macOS is actually certified and registered as Unix. It's my understanding that Apple paid a fair bit of money to make that happen: https://www.opengroup.org/openbrand/register/ - Dan C.

Warner Losh wrote in <CANCZdfqNxuT1XT-En8-9+5+bdkGJz3fzpE-f2wZ1GdQ9thnU7w(a)mail.gmail.com>om>: |On Thu, Jun 27, 2024, 6:07 AM Dan Cross <crossd(a)gmail.com> wrote: | |> On Thu, Jun 27, 2024 at 8:02 AM Peter Yardley |> <peter.martin.yardley(a)gmail.com> wrote: |>> OSX is Mach which has a BSD emulation layer. And BSD injected into the |> kernel. |>> |>> It doesn’t claim to be UNIX. |> |> Not true! It does: macOS is actually certified and registered as Unix. |> It's my understanding that Apple paid a fair bit of money to make that |> happen: https://www.opengroup.org/openbrand/register/ | |Indeed (can't authoritatively speak to the cost). FreeBSD has started |getting a trickle of fixes to cope with the test suite compliance. Some are |very test suite specific like checking to make sure argv[0] != NULL in some |weird programs... some fix real problems though.. I think POSIX tries to create a sane environment.. Early proposals required that the value of argc passed to main( ) be ``one or greater ’’. This was driven by the same requirement in drafts of the ISO C standard. In fact, historical implementations have passed a value of zero when no arguments are supplied to the caller of the exec functions. This requirement was removed from the ISO C standard and subsequently removed from this volume of POSIX.1-2024 as well. The wording, in particular the use of the word should, requires a Strictly Conforming POSIX Application to pass at least one argument to the exec function, thus guaranteeing that argc be one or greater when invoked by such an application. In fact, this is good practice, since many existing applications reference argv[0] without first checking the value of argc. ..whereas CVE-2021-4034a also caused FreeBSD commits like exit if invoked with invalid (zero) argc This was prompted by the recent pkexec vulnerability (CVE-2021-4034). This change is being made on general principle for setuid/setgid binaries and is not in response to an actual issue. and, furthermore execve: disallow argc == 0 The manpage has contained the following verbiage on the matter for just under 31 years: "At least one argument must be present in the array" Previous to this version, it had been prefaced with the weakening phrase "By convention." Carry through and document it the rest of the way. Allowing argc == 0 has been a source of security issues in the past, and it's hard to imagine a valid use-case for allowing it. Toss back EINVAL if we ended up not copying in any args for *execve(). Man, .. also two and a half year, that one.. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

On Thursday, June 27th, 2024 at 12:08 PM, Stuff Received <stuff(a)riddermarkfarm.ca> wrote: Leopard, the first UNIX-certified OS X, was certified to UNIX 03, which derives from 1003.1-2001, so POSIX cpio(1) it seems was never a factor. - Matt G.