Rollup merge of #63109 - alexcrichton:disable-windows-fs-test, r=sfackler

std: Fix a failing `fs` test on Windows

In testing 4-core machines on Azure the `realpath_works_tricky` test in
the standard library is failing with "The directory name is invalid". In
attempting to debug this test I was able to reproduce the failure
locally on my machine, and after inspecing the test it I believe is
exploiting Unix-specific behavior that seems to only sometimes work on
Windows. Specifically the test basically executes:

    mkdir -p a/b
    mkdir -p a/d
    touch a/f
    ln -s a/b/c ../d/e
    ln -s a/d/e ../f

and then asserts that `canonicalize("a/b/c")` and
`canonicalize("a/d/e")` are equivalent to `a/f`. On Windows however the
first symlink is a "directory symlink" and the second is a file symlink.
In both cases, though, they're pointing to files. This means that for
whatever reason locally and on the 4-core environment the call to
`canonicalize` is failing. On Azure today it seems to be passing, and
I'm not entirely sure why. I'm sort of presuming that there's some sort
of internals going on here where there's some global Windows setting
which makes symlinks behavior more unix-like and ignore the directory
hint.

In any case this should keep the test working and also fixes the test
locally for me. It's also worth pointing out that this test was made Windows compatible in https://github.com/rust-lang/rust/pull/31360, a pretty ancient PR at this point.
This commit is contained in:
Mazdak Farrokhzad 2019-07-30 05:37:44 +02:00 committed by GitHub
commit 2becb62166
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -3316,11 +3316,11 @@ mod tests {
fs::create_dir_all(&d).unwrap();
File::create(&f).unwrap();
if cfg!(not(windows)) {
symlink_dir("../d/e", &c).unwrap();
symlink_file("../d/e", &c).unwrap();
symlink_file("../f", &e).unwrap();
}
if cfg!(windows) {
symlink_dir(r"..\d\e", &c).unwrap();
symlink_file(r"..\d\e", &c).unwrap();
symlink_file(r"..\f", &e).unwrap();
}