[TUHS] another OSX 100% less Unix

[TUHS] another OSX 100% less Unix

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]

I have a directory, t:
ronsexcllentmbp:t rminnich$ ls -li
total 0
23801442 -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:21 a
23801443 -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 b
23801443 -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 c

note that b and c are the same inode.

let's make a cpio.

ronsexcllentmbp:t rminnich$ cpio -o >../t.cpio
a
b
c
^D
1 block

what's in it?
ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
-rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
-rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b
-rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b

"c link to b"? wtf? Who thought that was a good idea? because ...
ronsexcllentmbp:t rminnich$ touch 'c link to b'
ronsexcllentmbp:t rminnich$ ls -l
total 0
-rw-r--r--  1 rminnich  wheel  0 Jun 26 20:21 a
-rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 b
-rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 c
-rw-r--r--  1 rminnich  wheel  0 Jun 26 20:22 c link to b

and
ronsexcllentmbp:t rminnich$ cpio -o >../t.cpio
a
b
c
c link to b
^D

ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
-rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
-rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b
-rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
-rw-r--r--   1 rminnich wheel           0 Jun 26 20:22 c link to b

so ... it looks like a file is there twice, because somebody thought it was
a good idea to confuse a file name and file metadata. And, anyway, it's
just as accurate to have it say
-rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
-rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b link to c
-rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
-rw-r--r--   1 rminnich wheel           0 Jun 26 20:22 c link to b
Right? :-)

From the same people who brought you this:
ronsexcllentmbp:t rminnich$ bc
>>>

Somebody needs to get the osx folks a unix manual set :-)

[-- Attachment #2: Type: text/html, Size: 2525 bytes --]

[TUHS] Re: another OSX 100% less Unix

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]

and, yes, on linux, it behaves more properly
rminnich@pop-os:/tmp/t$ cpio -ivt < ../t.cpio
-rw-rw-r--   1 rminnich rminnich        0 Jun 26 20:29 a
-rw-rw-r--   2 rminnich rminnich        0 Jun 26 20:29 b
-rw-rw-r--   2 rminnich rminnich        0 Jun 26 20:29 c
1 block



On Wed, Jun 26, 2024 at 8:29 PM ron minnich <rminnich@gmail.com> wrote:

> I have a directory, t:
> ronsexcllentmbp:t rminnich$ ls -li
> total 0
> 23801442 -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:21 a
> 23801443 -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 b
> 23801443 -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 c
>
> note that b and c are the same inode.
>
> let's make a cpio.
>
> ronsexcllentmbp:t rminnich$ cpio -o >../t.cpio
> a
> b
> c
> ^D
> 1 block
>
> what's in it?
> ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
> -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
>
> "c link to b"? wtf? Who thought that was a good idea? because ...
> ronsexcllentmbp:t rminnich$ touch 'c link to b'
> ronsexcllentmbp:t rminnich$ ls -l
> total 0
> -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:21 a
> -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 b
> -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 c
> -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:22 c link to b
>
> and
> ronsexcllentmbp:t rminnich$ cpio -o >../t.cpio
> a
> b
> c
> c link to b
> ^D
>
> ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
> -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
> -rw-r--r--   1 rminnich wheel           0 Jun 26 20:22 c link to b
>
> so ... it looks like a file is there twice, because somebody thought it
> was a good idea to confuse a file name and file metadata. And, anyway, it's
> just as accurate to have it say
> -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b link to c
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
> -rw-r--r--   1 rminnich wheel           0 Jun 26 20:22 c link to b
> Right? :-)
>
> From the same people who brought you this:
> ronsexcllentmbp:t rminnich$ bc
> >>>
>
> Somebody needs to get the osx folks a unix manual set :-)
>

[-- Attachment #2: Type: text/html, Size: 3223 bytes --]

[TUHS] Re: another OSX 100% less Unix

[Leah Neukirchen]

ron minnich <rminnich@gmail.com> writes:

> I have a directory, t:
> ronsexcllentmbp:t rminnich$ ls -li
> total 0
> 23801442 -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:21 a
> 23801443 -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 b
> 23801443 -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 c
>
> note that b and c are the same inode.
>
> let's make a cpio.
>
> ronsexcllentmbp:t rminnich$ cpio -o >../t.cpio
> a
> b
> c
> ^D
> 1 block
>
> what's in it?
> ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
> -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
>
> "c link to b"? wtf? Who thought that was a good idea? because ...
> ronsexcllentmbp:t rminnich$ touch 'c link to b'
> ronsexcllentmbp:t rminnich$ ls -l
> total 0
> -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:21 a
> -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 b
> -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 c
> -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:22 c link to b

This is a feature of libarchive (cpio since FreeBSD 8), note that
without -v it prints the actual names as tools expect it.
(Similarly, symlinks are printed as "c -> b".)

More fun is that it's not able to extract only "c", even tho the ASCII
cpio format stores hard links by duplicating the data...

-- 
Leah Neukirchen  <leah@vuxu.org>  https://leahneukirchen.org/

[TUHS] Re: another OSX 100% less Unix

[Peter Yardley]

OSX is Mach which has a BSD emulation layer. And BSD injected into the kernel.

It doesn’t claim to be UNIX.

> On 27 Jun 2024, at 1:29 PM, ron minnich <rminnich@gmail.com> wrote:
> 
> I have a directory, t:
> ronsexcllentmbp:t rminnich$ ls -li
> total 0
> 23801442 -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:21 a
> 23801443 -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 b
> 23801443 -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 c
> 
> note that b and c are the same inode.
> 
> let's make a cpio.
> 
> ronsexcllentmbp:t rminnich$ cpio -o >../t.cpio
> a
> b
> c
> ^D
> 1 block
> 
> what's in it?
> ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
> -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
> 
> "c link to b"? wtf? Who thought that was a good idea? because ...
> ronsexcllentmbp:t rminnich$ touch 'c link to b'
> ronsexcllentmbp:t rminnich$ ls -l
> total 0
> -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:21 a
> -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 b
> -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 c
> -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:22 c link to b
> 
> and
> ronsexcllentmbp:t rminnich$ cpio -o >../t.cpio
> a
> b
> c
> c link to b
> ^D
> 
> ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
> -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
> -rw-r--r--   1 rminnich wheel           0 Jun 26 20:22 c link to b
> 
> so ... it looks like a file is there twice, because somebody thought it was a good idea to confuse a file name and file metadata. And, anyway, it's just as accurate to have it say
> -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b link to c
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
> -rw-r--r--   1 rminnich wheel           0 Jun 26 20:22 c link to b
> Right? :-)
> 
> From the same people who brought you this:
> ronsexcllentmbp:t rminnich$ bc
> >>>
> 
> Somebody needs to get the osx folks a unix manual set :-)

Peter Yardley
peter.martin.yardley@gmail.com

[TUHS] Re: another OSX 100% less Unix

[Dan Cross]

On Thu, Jun 27, 2024 at 8:02 AM Peter Yardley
<peter.martin.yardley@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/

        - Dan C.


> > On 27 Jun 2024, at 1:29 PM, ron minnich <rminnich@gmail.com> wrote:
> >
> > I have a directory, t:
> > ronsexcllentmbp:t rminnich$ ls -li
> > total 0
> > 23801442 -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:21 a
> > 23801443 -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 b
> > 23801443 -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 c
> >
> > note that b and c are the same inode.
> >
> > let's make a cpio.
> >
> > ronsexcllentmbp:t rminnich$ cpio -o >../t.cpio
> > a
> > b
> > c
> > ^D
> > 1 block
> >
> > what's in it?
> > ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
> > -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> > -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b
> > -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
> >
> > "c link to b"? wtf? Who thought that was a good idea? because ...
> > ronsexcllentmbp:t rminnich$ touch 'c link to b'
> > ronsexcllentmbp:t rminnich$ ls -l
> > total 0
> > -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:21 a
> > -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 b
> > -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 c
> > -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:22 c link to b
> >
> > and
> > ronsexcllentmbp:t rminnich$ cpio -o >../t.cpio
> > a
> > b
> > c
> > c link to b
> > ^D
> >
> > ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
> > -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> > -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b
> > -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
> > -rw-r--r--   1 rminnich wheel           0 Jun 26 20:22 c link to b
> >
> > so ... it looks like a file is there twice, because somebody thought it was a good idea to confuse a file name and file metadata. And, anyway, it's just as accurate to have it say
> > -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> > -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b link to c
> > -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
> > -rw-r--r--   1 rminnich wheel           0 Jun 26 20:22 c link to b
> > Right? :-)
> >
> > From the same people who brought you this:
> > ronsexcllentmbp:t rminnich$ bc
> > >>>
> >
> > Somebody needs to get the osx folks a unix manual set :-)
>
> Peter Yardley
> peter.martin.yardley@gmail.com
>

[TUHS] Re: another OSX 100% less Unix

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 3308 bytes --]

On Thu, Jun 27, 2024, 6:07 AM Dan Cross <crossd@gmail.com> wrote:

> On Thu, Jun 27, 2024 at 8:02 AM Peter Yardley
> <peter.martin.yardley@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..

Warner


>         - Dan C.
>
>
> > > On 27 Jun 2024, at 1:29 PM, ron minnich <rminnich@gmail.com> wrote:
> > >
> > > I have a directory, t:
> > > ronsexcllentmbp:t rminnich$ ls -li
> > > total 0
> > > 23801442 -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:21 a
> > > 23801443 -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 b
> > > 23801443 -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 c
> > >
> > > note that b and c are the same inode.
> > >
> > > let's make a cpio.
> > >
> > > ronsexcllentmbp:t rminnich$ cpio -o >../t.cpio
> > > a
> > > b
> > > c
> > > ^D
> > > 1 block
> > >
> > > what's in it?
> > > ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
> > > -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> > > -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b
> > > -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
> > >
> > > "c link to b"? wtf? Who thought that was a good idea? because ...
> > > ronsexcllentmbp:t rminnich$ touch 'c link to b'
> > > ronsexcllentmbp:t rminnich$ ls -l
> > > total 0
> > > -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:21 a
> > > -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 b
> > > -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 c
> > > -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:22 c link to b
> > >
> > > and
> > > ronsexcllentmbp:t rminnich$ cpio -o >../t.cpio
> > > a
> > > b
> > > c
> > > c link to b
> > > ^D
> > >
> > > ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
> > > -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> > > -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b
> > > -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
> > > -rw-r--r--   1 rminnich wheel           0 Jun 26 20:22 c link to b
> > >
> > > so ... it looks like a file is there twice, because somebody thought
> it was a good idea to confuse a file name and file metadata. And, anyway,
> it's just as accurate to have it say
> > > -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> > > -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b link to c
> > > -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
> > > -rw-r--r--   1 rminnich wheel           0 Jun 26 20:22 c link to b
> > > Right? :-)
> > >
> > > From the same people who brought you this:
> > > ronsexcllentmbp:t rminnich$ bc
> > > >>>
> > >
> > > Somebody needs to get the osx folks a unix manual set :-)
> >
> > Peter Yardley
> > peter.martin.yardley@gmail.com
> >
>

[-- Attachment #2: Type: text/html, Size: 4917 bytes --]

[TUHS] Re: another OSX 100% less Unix

[Stuff Received]

On 2024-06-26 23:29, ron minnich wrote (in part):
[...]
> what's in it?
> ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
> -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b
> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
> 
> "c link to b"? wtf? Who thought that was a good idea? because ...
> ronsexcllentmbp:t rminnich$ touch 'c link to b'
[...]
> 
> Somebody needs to get the osx folks a unix manual set :-)

Interestingly, the man page (macos 11.3.1) for cpio contains the following:

STANDARDS
      There is no current POSIX standard for the cpio command; it 
appeared in ISO/IEC 9945-1:1996
      (``POSIX.1'') but was dropped from IEEE Std 1003.1-2001 (``POSIX.1'').

      The cpio, ustar, and pax interchange file formats are defined by 
IEEE Std 1003.1-2001 (``POSIX.1'')
      for the pax command.

S.

[TUHS] Re: another OSX 100% less Unix

[segaloco via TUHS]

On Thursday, June 27th, 2024 at 12:08 PM, Stuff Received <stuff@riddermarkfarm.ca> wrote:

> On 2024-06-26 23:29, ron minnich wrote (in part):
> [...]
> 
> > what's in it?
> > ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
> > -rw-r--r-- 1 rminnich wheel 0 Jun 26 20:21 a
> > -rw-r--r-- 2 rminnich wheel 0 Jun 26 20:21 b
> > -rw-r--r-- 2 rminnich wheel 0 Jun 26 20:21 c link to b
> > 
> > "c link to b"? wtf? Who thought that was a good idea? because ...
> > ronsexcllentmbp:t rminnich$ touch 'c link to b'
> 
> [...]
> 
> > Somebody needs to get the osx folks a unix manual set :-)
> 
> 
> Interestingly, the man page (macos 11.3.1) for cpio contains the following:
> 
> STANDARDS
> There is no current POSIX standard for the cpio command; it
> appeared in ISO/IEC 9945-1:1996
> (`POSIX.1'') but was dropped from IEEE Std 1003.1-2001 (`POSIX.1'').
> 
> The cpio, ustar, and pax interchange file formats are defined by
> IEEE Std 1003.1-2001 (``POSIX.1'')
> for the pax command.
> 
> S.

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.

[TUHS] Re: another OSX 100% less Unix

[Bakul Shah via TUHS]

On Jun 27, 2024, at 2:47 AM, Leah Neukirchen <leah@vuxu.org> wrote:
> 
> ron minnich <rminnich@gmail.com> writes:
>> ronsexcllentmbp:t rminnich$ cpio -ivt < ../t.cpio
>> -rw-r--r--   1 rminnich wheel           0 Jun 26 20:21 a
>> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 b
>> -rw-r--r--   2 rminnich wheel           0 Jun 26 20:21 c link to b
>> 
>> "c link to b"? wtf? Who thought that was a good idea? because ...

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.

>> ronsexcllentmbp:t rminnich$ touch 'c link to b'
>> ronsexcllentmbp:t rminnich$ ls -l
>> total 0
>> -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:21 a
>> -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 b
>> -rw-r--r--  2 rminnich  wheel  0 Jun 26 20:21 c
>> -rw-r--r--  1 rminnich  wheel  0 Jun 26 20:22 c link to b
> 
> This is a feature of libarchive (cpio since FreeBSD 8), note that
> without -v it prints the actual names as tools expect it.
> (Similarly, symlinks are printed as "c -> b".)
> 
> More fun is that it's not able to extract only "c", even tho the ASCII
> cpio format stores hard links by duplicating the data...

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.