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

[Rainer Müller]

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?

Rainer

[1] https://opensource.apple.com/source/copyfile/