Skip to content

Commit 8d7fb87

Browse files
committed
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.
1 parent 04b88a9 commit 8d7fb87

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

src/libstd/fs.rs

+2-2
Original file line numberDiff line numberDiff line change
@@ -3316,11 +3316,11 @@ mod tests {
33163316
fs::create_dir_all(&d).unwrap();
33173317
File::create(&f).unwrap();
33183318
if cfg!(not(windows)) {
3319-
symlink_dir("../d/e", &c).unwrap();
3319+
symlink_file("../d/e", &c).unwrap();
33203320
symlink_file("../f", &e).unwrap();
33213321
}
33223322
if cfg!(windows) {
3323-
symlink_dir(r"..\d\e", &c).unwrap();
3323+
symlink_file(r"..\d\e", &c).unwrap();
33243324
symlink_file(r"..\f", &e).unwrap();
33253325
}
33263326

0 commit comments

Comments
 (0)