Cargo from rustup nightly as of Oct 28 2017 does not cargo build correctly on macOS 10.13 on APFS #4671

nelsonjchen · 2017-10-28T17:41:41Z

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.

The text was updated successfully, but these errors were encountered:

alexcrichton · 2017-10-28T17:47:43Z

Cc @kennytm, I wonder if we could use symlinks here as we will never execute this code on Windows?

kennytm · 2017-10-28T18:17:45Z

@alexcrichton Yes symlink should work. I thought the previous code would fail hardlink and fallback to do a deep-copy o_O.

Fixes rust-lang#4671.

biancode · 2017-10-29T08:21:37Z

same problem

cargo 0.24.0-nightly (e5562ddb0 2017-10-26)

| → cargo build
error: failed to link or copy `...target/debug/deps/appname-3058b71948163a55.dSYM` to `...target/debug/appname.dSYM`

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

nelsonjchen · 2017-10-29T08:28:33Z

As a workaround for now, I've been developing and building on a HFS+ sparse disk image which will still permit directory hardlinks in 10.13.

When uplifting directories, symlink them instead of hard-link them. Fixes #4671.

Fixes rust-lang#4671.

[beta] When uplifting directories, symlink them instead of hard-link them. Backport of #4672 to 1.22 (cargo 0.23) The current stable RC (cee38cd) contains #4616 *but not* #4672. Without the latter it is known to cause #4671 on APFS (enabled by default on macOS 10.13 "High Sierra"). The issue was found by kpy3 on https://internals.rust-lang.org/t/rust-1-22-0-prerelease-testing/6282/2.

jjgumucio · 2018-01-05T19:53:38Z

Sorri, I'm very new to Rust and it's ecosystem. I'm still having this issue. I tried to compile using the stable version of Rust but it gives me the same error.
Any help or suggestion would be greatly appreciated (My learning experience is frozen because of this!)

Thanks in advance

kennytm · 2018-01-05T21:18:00Z

@jjgumucio try to manually remove the target/ directory and try again?

Also, please show your rustc version by copying the output of rustc -vV here :).

We were sporadically but persistently seeing errors like failed to link or copy `.../target/debugs/deps/bin-264030cd6c8a02be.dSYM` to `.../target/debug/bin.dSYM` Caused by: the source path is not an existing regular file while running `cargo build`. Once the error occurs once, `cargo build` will fail forever with the same error until `target/debug/bin.dSYM` is manually unlinked. After some investigation, I've determined that this situation arises when the target of `bin.dSYM` goes missing. For example, if bin.dSYM is pointing at `deps/bin-86908f0fa7f1440e.dSYM`, and `deps/bin-86908f0fa7f1440e.dSYM` does not exist, then this error will occur. I'm still not clear on why the underlying dSYM bundle sporadically goes missing--perhaps it's the result of pressing Ctrl-C at the wrong moment?--but Cargo should at least be able to handle this situation better. It turns out that Cargo was getting confused by the broken symlink. When it goes to install the new `target/debug/bin.dSYM` link, it will remove the existing `target/debug/bin.dSYM` file, if it exists. Unfortunately, Cargo was checking whether the *target* of that symlink existed (e.g., `deps/bin-86908f0fa7f1440e.dSYM`, which in the buggy case would not exist), rather than the symlink itself, deciding that there was no existing symlink to remove, and crashing with EEXIST when trying to install the new symlink. This commit adjusts the existence check to evaluate whether the symlink itself exists, rather than its target. Note that while the symptoms are the same as rust-lang#4671, the root cause is unrelated.

Fix dSYM uplifting when symlink is broken We were sporadically but persistently seeing errors like failed to link or copy `.../target/debugs/deps/bin-264030cd6c8a02be.dSYM` to `.../target/debug/bin.dSYM` Caused by: the source path is not an existing regular file while running `cargo build`. Once the error occurs once, `cargo build` will fail forever with the same error until `target/debug/bin.dSYM` is manually unlinked. After some investigation, I've determined that this situation arises when the target of `bin.dSYM` goes missing. For example, if bin.dSYM is pointing at `deps/bin-86908f0fa7f1440e.dSYM`, and `deps/bin-86908f0fa7f1440e.dSYM` does not exist, then this error will occur. I'm still not clear on why the underlying dSYM bundle sporadically goes missing--perhaps it's the result of pressing Ctrl-C at the wrong moment?--but Cargo should at least be able to handle this situation better. It turns out that Cargo was getting confused by the broken symlink. When it goes to install the new `target/debug/bin.dSYM` link, it will remove the existing `target/debug/bin.dSYM` file, if it exists. Unfortunately, Cargo was checking whether the *target* of that symlink existed (e.g., `deps/bin-86908f0fa7f1440e.dSYM`, which in the buggy case would not exist), rather than the symlink itself, deciding that there was no existing symlink to remove, and crashing with EEXIST when trying to install the new symlink. This commit adjusts the existence check to evaluate whether the symlink itself exists, rather than its target. Note that while the symptoms are the same as #4671, the root cause is unrelated.

khoguan · 2020-06-21T08:08:31Z

I am sorry that I am still having the same issue when I cargo build a naive hello_world project on my Macbook Pro's internal APFS disk (macOS 10.15.5). If I cargo build on an external HFS+ disk, there will be no error. The output of running rustc -vV is:

rustc 1.44.1 (c7087fe00 2020-06-17)
binary: rustc
commit-hash: c7087fe00d2ba919df1d813c040a5d47e43b0fe7
commit-date: 2020-06-17
host: x86_64-apple-darwin
release: 1.44.1
LLVM version: 9.0

Would you please have a look at this issue again? Thanks a lot.

ehuss · 2020-06-21T16:23:18Z

@khoguan Can you run cargo with the CARGO_LOG=cargo::util::paths=trace environment variable and report what it displays?

khoguan · 2020-06-22T03:33:40Z

@ehuss Thanks for your kind help and hint. I just found that my issue is different from this one (#4671). I did not cargo build directly on APFS, which would have been OK. Instead, my cargo project is on a virtual disk of Google Drive File Stream (Version: 39.0.10.0) on top of APFS. The relevant item of mount is:

drivefs       on         /Volumes/GoogleDrive  (dfsfuse_DFS,              local,    nodev,        nosuid,     synchronous,  mounted  by  khoguan)

Here is the output of CARGO_LOG=cargo::util::paths=trace cargo build:

   Compiling hello_world v0.1.0 (/Volumes/GoogleDrive/My Drive/hello_world)
[2020-06-22T03:11:07Z DEBUG cargo::util::paths] invocation time for "/Volumes/GoogleDrive/My Drive/hello_world/target/debug/.fingerprint/hello_world-6706d124191574b7" is 1592795467.000000000s
warning: Hard linking files in the incremental compilation cache failed. Copying files instead. Consider moving the cache directory to a file system which supports hard linking in session dir `/Volumes/GoogleDrive/My Drive/hello_world/target/debug/incremental/hello_world-3lr0nf7wfwzik/s-folk4weenq-3aqig3-working`

warning: 1 warning emitted

[2020-06-22T03:11:07Z DEBUG cargo::util::paths] linking /Volumes/GoogleDrive/My Drive/hello_world/target/debug/deps/hello_world to /Volumes/GoogleDrive/My Drive/hello_world/target/debug/hello_world
[2020-06-22T03:11:07Z DEBUG cargo::util::paths] link failed Function not implemented (os error 78). falling back to fs::copy
[2020-06-22T03:11:07Z DEBUG cargo::util::paths] linking /Volumes/GoogleDrive/My Drive/hello_world/target/debug/deps/hello_world.dSYM to /Volumes/GoogleDrive/My Drive/hello_world/target/debug/hello_world.dSYM
[2020-06-22T03:11:07Z DEBUG cargo::util::paths] link failed Operation not supported (os error 45). falling back to fs::copy
error: failed to link or copy `/Volumes/GoogleDrive/My Drive/hello_world/target/debug/deps/hello_world.dSYM` to `/Volumes/GoogleDrive/My Drive/hello_world/target/debug/hello_world.dSYM`

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

alexcrichton · 2020-06-23T14:55:44Z

Ah that looks like a bug in Cargo, @khoguan mind opening a separate issue for that?

kennytm added a commit to kennytm/cargo that referenced this issue Oct 28, 2017

When uplifting directories, symlink them instead of hard-link them.

53e90d7

Fixes rust-lang#4671.

kennytm mentioned this issue Oct 28, 2017

When uplifting directories, symlink them instead of hard-link them. #4672

Merged

sinkuu mentioned this issue Oct 29, 2017

Linking issue with rust nightly rust-lang/rust#45607

Closed

bors added a commit that referenced this issue Oct 29, 2017

Auto merge of #4672 - kennytm:fix-4671, r=alexcrichton

859c230

When uplifting directories, symlink them instead of hard-link them. Fixes #4671.

bors closed this as completed in #4672 Oct 29, 2017

This was referenced Oct 31, 2017

fix tests japaric/xargo#173

Merged

"failed to remove .dSYM" when cross compiling to 32-bit macOS #4699

Closed

kennytm added a commit to kennytm/cargo that referenced this issue Nov 22, 2017

When uplifting directories, symlink them instead of hard-link them.

2c6a0fe

Fixes rust-lang#4671.

kennytm mentioned this issue Nov 22, 2017

[beta] When uplifting directories, symlink them instead of hard-link them. #4739

Merged

ilovezfs mentioned this issue Jan 12, 2018

Install rust failed Homebrew/homebrew-core#22776

Closed

5 tasks

benesch mentioned this issue Aug 19, 2019

Fix dSYM uplifting when symlink is broken #7268

Merged

khoguan mentioned this issue Jun 23, 2020

cargo build on Google Drive File Stream fails to link or copy .dSYM #8401

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cargo from rustup nightly as of Oct 28 2017 does not cargo build correctly on macOS 10.13 on APFS #4671

Cargo from rustup nightly as of Oct 28 2017 does not cargo build correctly on macOS 10.13 on APFS #4671

nelsonjchen commented Oct 28, 2017

alexcrichton commented Oct 28, 2017

kennytm commented Oct 28, 2017

biancode commented Oct 29, 2017

nelsonjchen commented Oct 29, 2017 •

edited

Loading

jjgumucio commented Jan 5, 2018

kennytm commented Jan 5, 2018

khoguan commented Jun 21, 2020

ehuss commented Jun 21, 2020

khoguan commented Jun 22, 2020 •

edited

Loading

alexcrichton commented Jun 23, 2020

Cargo from rustup nightly as of Oct 28 2017 does not cargo build correctly on macOS 10.13 on APFS #4671

Cargo from rustup nightly as of Oct 28 2017 does not cargo build correctly on macOS 10.13 on APFS #4671

Comments

nelsonjchen commented Oct 28, 2017

alexcrichton commented Oct 28, 2017

kennytm commented Oct 28, 2017

biancode commented Oct 29, 2017

nelsonjchen commented Oct 29, 2017 • edited Loading

jjgumucio commented Jan 5, 2018

kennytm commented Jan 5, 2018

khoguan commented Jun 21, 2020

ehuss commented Jun 21, 2020

khoguan commented Jun 22, 2020 • edited Loading

alexcrichton commented Jun 23, 2020

nelsonjchen commented Oct 29, 2017 •

edited

Loading

khoguan commented Jun 22, 2020 •

edited

Loading