rustbuild: Switch back to using hard links #44260
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors r+ p=1 (may speed up builds) |
|
📌 Commit 53f6404 has been approved by |
|
⌛ Testing commit 53f64045c9b5fee475c41ddf271a8fa799609102 with merge 3bc47abcfba717e2172768a4f2e0a93157b260e2... |
|
💔 Test failed - status-appveyor |
|
|
arielb1
added
the
S-waiting-on-author
|
@bors r+ |
|
📌 Commit 5381c40 has been approved by |
Mark-Simulacrum
added
S-waiting-on-bors
|
@bors: r- er sorry accidentally pushed, still investigating |
aidanhs
added
S-waiting-on-author
|
@bors: r=Mark-Simulacrum |
|
📌 Commit 5381c40 has been approved by |
alexcrichton
force-pushed
the
hardlink-no-copy
branch
from
5381c40 to
71318a6
Compare
|
@bors: r=Mark-Simulacrum |
|
📌 Commit 71318a6 has been approved by |
|
⌛ Testing commit 71318a65c7b9b485dd92e34074ec85f79c875754 with merge ab0b9195df04f09f53af8ab224446272dc2c0c10... |
|
💔 Test failed - status-travis |
The `copy` function historically in rustbuild used hard links to speed up the copy operations that it does. This logic was backed out, however, in rust-lang#39518 due to a bug that only showed up on Windows, described in rust-lang#39504. The cause described in rust-lang#39504 happened because Cargo, on a fresh build, would overwrite the previous artifacts with new hard links that Cargo itself manages. This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer should overwrite files on fresh builds, opportunistically leaving the filesystem intact and not touching it. Hopefully this can help speed up local builds by doing fewer copies all over the place!
alexcrichton
force-pushed
the
hardlink-no-copy
branch
from
71318a6 to
38bedfa
Compare
|
@bors: r=Mark-Simulacrum |
|
📌 Commit 38bedfa has been approved by |
rustbuild: Switch back to using hard links The `copy` function historically in rustbuild used hard links to speed up the copy operations that it does. This logic was backed out, however, in #39518 due to a bug that only showed up on Windows, described in #39504. The cause described in #39504 happened because Cargo, on a fresh build, would overwrite the previous artifacts with new hard links that Cargo itself manages. This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer should overwrite files on fresh builds, opportunistically leaving the filesystem intact and not touching it. Hopefully this can help speed up local builds by doing fewer copies all over the place!
|
☀️ Test successful - status-appveyor, status-travis |
| { | ||
| let mut s = t!(fs::File::open(&src)); | ||
| let mut d = t!(fs::File::create(&dst)); | ||
| io::copy(&mut s, &mut d).expect("failed to copy"); |
There was a problem hiding this comment.
just curious; is this construction different from fs::copy?
There was a problem hiding this comment.
Apparently on Windows yeah, I didn't dig too deeply.
The
copyfunction historically in rustbuild used hard links to speed up thecopy operations that it does. This logic was backed out, however, in #39518 due
to a bug that only showed up on Windows, described in #39504. The cause
described in #39504 happened because Cargo, on a fresh build, would overwrite
the previous artifacts with new hard links that Cargo itself manages.
This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer
should overwrite files on fresh builds, opportunistically leaving the filesystem
intact and not touching it.
Hopefully this can help speed up local builds by doing fewer copies all over the
place!