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

Rainer Müller raimue at
Tue Dec 19 14:09:25 UTC 2017

On 2017-12-18 00:20, Clemens Lang wrote:
> We debugged this on IRC recently. Turns out the culprit is
> /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:


#include <copyfile.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
    int ret;

    ret = copyfile("/usr/bin/tar", "/tmp/tar", NULL,
    if (ret) {
        return 1;

    return 0;


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?



More information about the macports-dev mailing list