NAS drives either don't work at all or are replaced by UNC paths on Windows

[dertuxmalwieder]

Describe the bug

Not quite a duplicate of (but related to) bug #686 which was closed for no technical reason: On Windows 11 at least, cd \\<NAS> will have the wrong results, leading to Nushell not being able to actually use the network drive.

Real-world example (my NAS is named "datengrab"):

〉cd \\datengrab
Error: nu::shell::directory_not_found (link)

  × Directory not found
   ╭─[entry #1:1:1]
 1 │ cd \\datengrab
   ·    ─────┬─────
   ·         ╰── directory not found
   ╰────
  help: IO Error: Os { code: 2, kind: NotFound, message: "Das System kann die angegebene Datei nicht finden." }

Using a subdirectory "works" though:

〉cd \\datengrab\musik_todo
\\?\UNC\datengrab\Musik_TODO〉

The ?\UNC\ part leads to further issues, as most software considers the path as invalid. In fact, even NuShell itself can't use it:

\\?\UNC\datengrab\Musik_TODO〉ls
Error:
  × No matches found for ./*
  help: no matches found

It all works fine in cmd and PowerShell.

How to reproduce

1. Set up a NAS.
2. Connect to it as a network drive on Windows 11.
3. cd to it.

Expected behavior

I expected NuShell to behave just like most other Windows utilities and not use \\?\UNC paths.

Screenshots

No response

Configuration

key	value
version	0.67.0
branch
commit_hash	91976988f032276ca48faff2d1ac13c079eda836
build_os	windows-x86_64
build_target	x86_64-pc-windows-msvc
rust_version	rustc 1.63.0 (4b91a6ea7 2022-08-08)
rust_channel	stable-x86_64-pc-windows-msvc
cargo_version	cargo 1.63.0 (fd9c4297c 2022-07-01)
pkg_version	0.67.0
build_time	2022-08-17 15:20:56 +00:00
build_rust_channel	release
features	database, dataframe, default, trash, which, zip
installed_plugins

Additional context

No response

[fdncred]

Agreed. UNC on Windows is an issue. We'd love to have a PR to support this better.

[dertuxmalwieder]

The problem seems to be that Nushell uses the dunce crate to get rid of UNC (at least in some places):

This crate (...) leaves UNC paths as-is when they can’t be unambiguously expressed in a simpler way.

There is an open bug report which, once fixed, would (seemingly) solve this issue, but it has been open for quite some time:
https://gitlab.com/kornelski/dunce/-/issues/2

[fdncred]

Maybe someone should fork it and fix it finally.

[dertuxmalwieder]

According to the source code, it could be sufficient to just adapt the canonicalize_win() function instead of having a whole new dependency...?

[charlesroper]

There is an open bug report which, once fixed, would (seemingly) solve this issue, but it has been open for quite some time:
https://gitlab.com/kornelski/dunce/-/issues/2

This dunce issue has just been closed but unfortunately no fix. Looks like author has abandoned it.

[dertuxmalwieder]

Indeed. That leaves no (obvious) other choice than what I proposed above. :-/

[fdncred]

dang, someone should just fork it and fix it. then we can repoint ours there.

[rgwood]

This should be partially fixed by #6824 (part of the upcoming Nushell v0.71 release).

cd \\my-server doesn't seem to work but cd \\my-server\some-dir does, and ls inside some-dir works now.

[ChrisDenton]

Yeah, \\my-server isn't a proper Windows path so can't be used for normal filesystem operations. To list the share names on a samba server you'd need to use something like NetShareEnum to enumerate them.

[dertuxmalwieder]

This should be partially fixed by #6824 (part of the upcoming Nushell v0.71 release).

Confirmed. As far as it concerns my original ticket, I consider this fixed... :)