nightly cargo can no longer build anything due to error: failed to create directory `...\target` Caused by: Incorrect function. (os error 1)

[nabijaczleweli]

I tried this code:

cargo +nightly build

I expected to see this happen: the crate builds

Instead, this happened:

[some "Fetching"s happen on first run]
error: failed to create directory `s:\imgdiff-real\target`

Caused by:
  Incorrect function. (os error 1)

Happens to every crate any where I put it. I can obviously manually create this. Stable can build these too.

Meta

rustc +nightly --version --verbose:

rustc 1.87.0-nightly (46420c960 2025-02-22)
binary: rustc
commit-hash: 46420c96070b4c4bd8242f16d5806b8f26a57016
commit-date: 2025-02-22
host: x86_64-pc-windows-gnu
release: 1.87.0-nightly
LLVM version: 20.1.0

Stable still works

rustc 1.84.1 (e71f9a9a9 2025-01-27)
binary: rustc
commit-hash: e71f9a9a98b0faf423844bf0ba7438f29dc27d58
commit-date: 2025-01-27
host: x86_64-pc-windows-gnu
release: 1.84.1
LLVM version: 19.1.5

[ChrisDenton]

Is this on an imdisk ram drive?

[nabijaczleweli]

Happens on real disk (local, SATA, NTFS) but can also repro on SoftPerfect RAM Disk.

[ChrisDenton]

Hm, a usual reason for this error is std::fs::canonicalize failing on a drive that doesn't support it. However, Cargo uses fallbacks for that situation so I wondered if there was a regression there. Failing on normal drives would rule that out.

Failing to create a directory with that error is highly unusual. I can't yet repro it on my machine using the latest nightly.

Does it work if you manually create the target directory?

[nabijaczleweli]

(SoftPerfect supports canonicalisation, I build crates there all the time; neither here nor there since this also happens on real disks)

It does for a bit until it tries to create another:

   Compiling crossbeam-utils v0.8.20
   Compiling log v0.4.22
   Compiling bumpalo v3.16.0
error: failed to write S:\imgdiff-real\target\debug\deps\libcfg_if-5e710c05facb79fe.rmeta: Incorrect function. (os error 1)

error: could not compile `cfg-if` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: failed to write S:\imgdiff-real\target\debug\deps\libunicode_ident-ae96588ddcd89e94.rmeta: Incorrect function. (os error 1)

error: could not compile `unicode-ident` (lib) due to 1 previous error
error: failed to write S:\imgdiff-real\target\debug\deps\liblog-f4025ca40747ecd5.rmeta: Incorrect function. (os error 1)

error: could not compile `log` (lib) due to 1 previous error
error: failed to write S:\imgdiff-real\target\debug\deps\libbumpalo-e9bda64ade8b9f52.rmeta: Incorrect function. (os error 1)

error: failed to write S:\imgdiff-real\target\debug\deps\libautocfg-ed612dc94a4d1095.rmeta: Incorrect function. (os error 1)

error: could not compile `bumpalo` (lib) due to 1 previous error
error: could not compile `autocfg` (lib) due to 1 previous error

[ChrisDenton]

Do you have any security software that might be interfering with the build?

[nabijaczleweli]

No, and the nightlies have always worked before (admittedly, I don't build on nightly all that often) and my setup hasn't changed. Is there something I can do to bisect this to some syscall or function call? Maybe a symbol to step through? Blindly attaching gdb and hoping when the compiler isn't even panicking/aborting/whatever seems like a fool's errand.

[ChrisDenton]

You could try cargo-bisect-rustc https://rust-lang.github.io/cargo-bisect-rustc/installation.html

To narrow down the nightly that started failing.

[ChrisDenton]

Otherwise there's process monitor to look at the failing function calls https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

[nabijaczleweli]

cargo bisect-rustc --access=github --start=2024-10-01 --end=2025-01-27 seems to have started well so far. Bisect running.

[nabijaczleweli]

Reproed on plain cargo new foo, no additional arguments.

searched nightlies: from nightly-2024-10-01 to nightly-2025-01-27
regressed nightly: nightly-2024-12-23
searched commit range: 426d173...e108481
regressed commit: 00bf74d

bisected with cargo-bisect-rustc v0.6.9

Host triple: x86_64-pc-windows-gnu
Reproduce with:

cargo bisect-rustc --access=github --start=2024-10-01 --end=2025-01-27

[ChrisDenton]

Ah most likely https://github.com/rust-lang/rust/pull/131072/files

I'll put up a PR tomorrow to hopefully fix this.

What's your Windows version btw?