nu 0.60 beta cannot ls in a UNC share

[anisoptera]

Describe the bug

This works on 0.44.0 (released non-beta). If you cd to a UNC share in the 0.60.0 beta, ls doesn't work. Instead of listing files I get an error about ./*: not found.

I can still cd to directories I know exist, but listing files fails no matter what directory I'm in on the share.

How to reproduce

1. cd to a UNC share (\servername\sharename)
2. type ls

Expected behavior

List files in a fancy table

Screenshots

No response

Configuration

No response

Additional context

No response

[anisoptera]

Hmm, on digging slightly deeper, even on nushell 0.44.0 the UNC support is not great:

\\?\UNC\filez\media\movies> ls convert.zsh
───┬─────────────┬──────┬───────┬───────────
 # │    name     │ type │ size  │ modified
───┼─────────────┼──────┼───────┼───────────
 0 │ convert.zsh │ File │ 703 B │ a day ago
───┴─────────────┴──────┴───────┴───────────

\\?\UNC\filez\media\movies> cp convert.zsh convert.nu
error: No matches found
   ┌─ shell:19:4
   │
19 │ cp convert.zsh convert.nu
   │    ^^^^^^^^^^^ no matches found

[fdncred]

I'm betting that our nu-path crate doesn't understand UNC yet. hmmmmm, after looking a bit, it used dunce which should work with UNC. so maybe something else is going on.

[fdncred]

this seems to work

> ls \\localhost\admin$ 
╭─────┬──────────────────────────────────────────────────────────────────┬──────┬──────────┬────────────────╮
│  #  │                               name                               │ type │   size   │    modified    │
├─────┼──────────────────────────────────────────────────────────────────┼──────┼──────────┼────────────────┤
│   0 │ \\localhost\admin$\AppReadiness                                  │ dir  │      0 B │ 44 minutes ago │
│   1 │ \\localhost\admin$\Boot                                          │ dir  │   4.1 KB │ 9 months ago   │
│   2 │ \\localhost\admin$\Branding                                      │ dir  │      0 B │ 9 months ago   │
│   3 │ \\localhost\admin$\BrowserCore                                   │ dir  │      0 B │ 9 months ago   │
│   4 │ \\localhost\admin$\CSC                                           │ dir  │      0 B │ 2 years ago    │
│   5 │ \\localhost\admin$\CbsTemp                                       │ dir  │   4.1 KB │ a week ago     │
│   6 │ \\localhost\admin$\Containers                                    │ dir  │      0 B │ 9 months ago   │

but if i do this cd \\localhost\admin$ and then try ls i get:

Error:
  × No matches found for ./*
  help: no matches found

> $env.PWD
\\?\UNC\localhost\admin$

> ls $env.PWD
Error:
  × No matches found for \\?\UNC\localhost\admin$\*
  help: no matches found

[fdncred]

I think this is the problem. Our glob crate doesn't know what to do with VerbatimUNC paths.

nushell/crates/nu-glob/src/lib.rs

Lines 226 to 239 in 6e69d40

	if root_len > 0
	&& check_windows_verbatim(root.expect("internal error: already checked for len > 0"))
	{
	// FIXME: How do we want to handle verbatim paths? I'm inclined to
	// return nothing, since we can't very well find all UNC shares with a
	// 1-letter server name.
	return Ok(Paths {
	dir_patterns: Vec::new(),
	require_dir: false,
	options,
	todo: Vec::new(),
	scope: None,
	});
	}

unc path

root=[Some("\\\\?\\UNC\\localhost\\admin$\\")]

path components

p=PrefixComponent { raw: "\\\\?\\UNC\\localhost\\admin$", parsed: VerbatimUNC("localhost", "admin$") }

[MCoooo]

Hi, this issue is caused by the PWD using UNC. If PWD is set to drive format, e.g. let-env PWD = "L:\Scripts" , all is well.

[anisoptera]

Yes, the bug is specifically about the pwd being a UNC path. I don’t want to have to map a drive letter to use a share. I can’t switch away from powershell without feature parity :)

[MCoooo]

Ah sorry - reading helps! I raised a similar issue but for drive map use case but didn't pick up on this distinction (folded into here as dup).

While being very much on at the start of my Rust (and GitHub) journey and without understanding the implication, but wishing to use nu on a daily basis, I've forked and and swapped \\?\UNC\ to \\ in cwd in env.rs.

Hasn't broken yet. If of any use...

https://github.com/MCoooo/nushell_hack

Hopefully get time to understand what's going on more fully

[MCoooo]

After removing the condition
'if root_len > 0
&& check_windows_verbatim(root.expect("internal error: already checked for len > 0"))'

and using a verbatim path, nu ls does generate a contents list but not as expected. When change directory uses a verbatim path some auto correction takes place where needed (device to unc and case for example). When ls is used directly against a verbatim, there is no autocorrection, however it does generate a list.

However verbatim paths currently do no just display the files but some of the path, so I assume the 'name' object is incorrect for use in piped commands.

Not sure of the QA benchmarks for changes, but I would argue its better to promote adoption in the Windows (Enterprise) space with this limitation / rough edge. Unless of course more is broken...

[charlesroper]

I came across this issue trying to CD into WSL. My Ubuntu WSL instance is mapped to U: but the path gets converted to a UNC path.

There's an open issue about this for zoxide: ajeetdsouza/zoxide#162

Which leads to a problem with dunce: https://gitlab.com/kornelski/dunce/-/issues/2

Could this be the problem?

[fdncred]

cd is not the same as ls, of course, but this problem could be related. we use dunce as well but switching from dunce to crate x may not solve the problem this issue states (but it may solve the cd'ing issue). I spelled out above what I thought the issue was with verbatimunc paths.

[charlesroper]

Sorry, I wasn't clear! cd'ing works. The error you see in my screenshot is Zoxide failing (maybe because of dunce). I can, however, still type commands. If I invoke ls, it gives me the error this issue is about.

Not sure if these things are related or not, but seemed worth mentioning.

[fdncred]

i'm guessing they're related but someone would have look at the ls code and debug it probably.

[ehawman]

Wanted to chime in by saying that recently I've been getting a more aggressive error message.

Not sure if this is due to some third-party application or if there are just more debug options in Nu now.

I should note here that I have pwd as

def pwd [] {
    echo $env.PWD | sd \\ /
}

Hence the forward slashes, but both manual entry and cd pwd results in the same gobbledygook.

[fdncred]

@ehawman That's weird. Those look like dotnet errors. nushell doesn't have any dotnet but on Windows it may call into the Windows API that is dotnet.

[rgwood]

Good news, UNC issues should be fixed by #6824. The fix will be released in Nushell v0.71.

[MCoooo]

Fantastic. Great work all.

[charlesroper]

Thank you so much folks! Especially @ChrisDenton for omnipath. 🙏