Cargo fails to hardlink/copy .dSYM symbols to the target location on APFS. I think this might be related to these new .dSYM folders instead of the .d files that rustc now generates.

I tried this: cargo new --bin dsym_demo && cd dsym_demo && cargo build

I expected to see this happen: No errors.

Instead, this happened:

   Compiling dsym_demo v0.1.0 (file:///Users/nelson/code/dsym_demo)
error: failed to link or copy `/Users/nelson/code/dsym_demo/target/debug/deps/dsym_demo-4c56824b529ce2eb.dSYM` to `/Users/nelson/code/dsym_demo/target/debug/dsym_demo.dSYM`

Caused by:
  the source path is not an existing regular file

I'm using cargo 0.24.0-nightly (e5562ddb0 2017-10-26). I'm running macOS 10.13. I'm using APFS.

Here's a debug log of RUST_LOG=debug cargo build:

https://gist.github.com/nelsonjchen/7d082de8def7fb8c23b714139f729795

I'm not too versed in cargo's internals but I believe that it tries to hardlink files/directories before falling back to std::fs::copy. Now the hard link worked on 10.12 on HFS and I believe that's what the build machines for the Rust project are running. It also works in this Travis build I just ran for that dsym_demo project I mentioned. In these cases, I think the hard link of the .dSYM symbols directory succeeds without error.

I also fell back to stable which still uses the older .d file symbols. On 10.13 with APFS, this is still fine.

So, hard linking works for the older .d file symbols on 10.13 with APFS and also .dSYM on 10.12 with HFS. But when these new .dSYM symbol "folders" appear and we're on APFS, it does not work as hard links are not supported for directories and std::fs::copy will not copy the directory "file".

Here's a related issue where some users discuss that directory hard linking is no longer supported in 10.13 on APFS:

selkhateeb/hardlink#31

A user in that discussion even mentions that the FAQ explicitly mentions APFS does not support directory hardlinks anymore. During the HFS->APFS conversion, they get transformed to symlinks.