trace mode fails with sh: /usr/bin/tar: No such file or directory

[Joshua Root]

On 2017-12-20 01:09 , Rainer Müller wrote:
> On 2017-12-18 00:20, Clemens Lang wrote:
>> We debugged this on IRC recently. Turns out the culprit is
>>   https://github.com/macports/macports-base/commit/3d4c9b342d28abd0b7aaf7eb70fa4862e898542c#diff-94a7b4a6e8f8c93116146f83a92a7f44
>>
>> /usr/bin/tar is a symlink to bsdtar. copyfile(3) copies the symlink, the
>> previous method opened the file (dereferencing the symlink) and copied
>> its contents.
>>
>> When the symlink is copied (because copyfile(3) is used), the
>> destination of the symlink is not copied, which eventually leads to file
>> not found.
> 
> According to the documentation of copyfile(3), it should always follow
> the symlink unless COPYFILE_NOFOLLOW was specified. I even checked its
> implementation [1]. Internally, clonefileat(2) will only be called with
> CLONE_NOFOLLOW when COPYFILE_NOFOLLOW was given – and we do not do that.
> 
> I did a quick test with the following code snippet which should be
> roughly equivalent to what we use in our sip_copy_proc.c:
> 
> ---8<---
> 
> #include <copyfile.h>
> #include <stdio.h>
> 
> int main(int argc, char *argv[]) {
>     int ret;
> 
>     ret = copyfile("/usr/bin/tar", "/tmp/tar", NULL,
>               COPYFILE_ALL | COPYFILE_CLONE);
>     if (ret) {
>         perror("copyfile");
>         return 1;
>     }
> 
>     return 0;
> }
> 
> --->8---
> 
> I could not reproduce the problem as described on 10.12.6 Sierra. After
> running this program, /tmp/tar is a regular file and contains the same
> contents as /usr/bin/bsdtar.
> 
> I also tested on a VM with 10.13.0 High Sierra, as I still had that
> around. It also works there as expected.
> 
> Does this mean Apple has a regression how copyfile(3) works with
> symlinks on macOS 10.13.2? Can somebody with 10.13.2 please test the
> code above and confirm this?

Yep, looks like it. :(

% ls -l /tmp/tar
lrwxr-xr-x  1 josh  wheel  6  1 Oct 06:07 /tmp/tar -> bsdtar

- Josh