[TUHS] Re: another OSX 100% less Unix

[Bakul Shah via TUHS <tuhs@tuhs.org>]

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.