Test on Windows with an actual file called NUL

This covers a possible concern pertaining to a forthcoming minor
gix-testtools bugfix.

The null device, accessible as `/dev/null` on a Unix-like system,
or as `NUL` (and in some other ways) on Windows, is the best
candidate to replace the current value of `:` (on Unix) or `-`
(on Windows) for `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL` when
test fixture scripts are running.

This is because the filenames `:` (on Unix) and `-` (on Windows) do
not have any special meaning. They are valid but unusual filenames;
files of these names most often do not exist, but can, and when
they do, their contents are used the populate the system or global
scope for test fixtures, which is not the intended behavior. `git`
does not treat them as anything but filenames: a `:` is not treated
as a separator because those variables are interpreted as single
paths rather than lists of paths, and a `-` is not treated to mean
standard input (or any other special data source) because it
appears in an environment variable rather than as a command-line
argument.

But `/dev/null` and `NUL` can exist, too.

On Unix, where `/dev/null` should be used, the whole point is that
`/dev/null` exists. That absolute path is not treated specially.
Instead, the device node for the null device is linked there.

On Windows, where the null device is named `NUL`, an entry for it
with that name does also sort of exist in the filesystem,
accessible via the fully qualified device path `\\.\NUL` as well as
by some other fully qualified forms such as `\??\NUL`. However, not
all interfaces support all path forms, so accessing it in those
ways is not necessarily more robust than accessing it with the
relative path `NUL`.

Yet it is possible for an actual file, not the null device, to
exist with the name `NUL` in an arbitrary directory. Such a file
can only be referred to using the UNC syntax with a `\\?\` prefixed
path (not to be confused with the `\\.\` device namespace prefix,
nor the NT `\??\` prefix).

When such a file exists, `NUL` itself still does not refer to it;
`NUL` still refers to the null device. The additon to the test here
(and refactorings to support it) create an acutal file called `NUL`
to demonstrate that changing `-` to `NUL` really does avoid getting
a configuration file, regardless of what files exist.

Author: EliahKagan

tests/tools/src/lib.rs

@@ -887,16 +887,18 @@ mod tests {
 
     fn check_configure_clears_scope(scope_env_key: &str, scope_option: &str) {
         let scope_env_value = "gitconfig";
-
-        #[cfg(windows)]
-        let names = [scope_env_value, "-"];
-        #[cfg(not(windows))]
-        let names = [scope_env_value, "-", ":"];
-
         let temp = tempfile::TempDir::new().expect("can create temp dir");
+        let dir = temp.path();
+
+        let paths: &[PathBuf] = if cfg!(windows) {
+            let unc_literal_nul = dir.canonicalize().expect("directory exists").join("NUL");
+            &[dir.join(scope_env_value), dir.join("-"), unc_literal_nul]
+        } else {
+            &[dir.join(scope_env_value), dir.join("-"), dir.join(":")]
+        };
 
-        for name in names {
-            File::create_new(temp.path().join(name))
+        for path in paths {
+            File::create_new(path)
                 .expect("can create file")
                 .write_all(b"[foo]\n\tbar = baz\n")
                 .expect("can write contents");
@@ -905,7 +907,7 @@ mod tests {
         let mut cmd = std::process::Command::new("git");
         cmd.env(scope_env_key, scope_env_value); // configure_command() should override it.
         let args = ["config", "-l", "--show-origin", scope_option].map(String::from);
-        configure_command(&mut cmd, &args, temp.path());
+        configure_command(&mut cmd, &args, dir);
 
         let output = cmd.output().expect("can run git");
         let stdout = output.stdout.to_str().expect("valid UTF-8");