Files with trailing dots (or spaces) break nushell on Windows #7869
Comments
spf13
changed the title
spf13
changed the title
|
This is fundamentally a consequence of how Win32 APIs work. They strip trailing dots from paths when called. MINGW bash uses lower level (NT) APIs that don't do this. It's also possible to use verbatim paths to workaround this issue. |
|
I guess the |
sholderbach
added
🐛 bug
|
The error message is better in recent versions of Nu: #7348 It would be nice to handle this as well as MINGW bash but tbh it's not a high priority; edit: I misremembered, Explorer does show the files. If someone has time we should do this. |
|
cmd, Windows Explorer and PowerShell all show these files. They struggle
to open, move or rename the file/directory, but Windows explorer even lets
you show the properties of it.
It's odd that Nu errors instead of listing.
…On Fri, Jan 27, 2023 at 7:19 AM Reilly Wood ***@***.***> wrote:
The error message is better in recent versions of Nu: #7348
<#7348>
It would be nice to handle this as well as MINGW bash but tbh it's not a
high priority; IIRC Windows Explorer/cmd/PowerShell don't even show these
files.
—
Reply to this email directly, view it on GitHub
<#7869 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABKKZALKR4JVINRDEQJJJTWUO4O3ANCNFSM6AAAAAAUIHH6YQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Yeah, I corrected my comment shortly after posting (currently travelling and on very little sleep) |
|
If anyone wants to tackle this, this is the relevant place in nushell/crates/nu-command/src/filesystem/ls.rs Lines 688 to 691 in 76292ef It's pretty easy to give up and return nothing for metadata columns when That might be good enough as a quick-and-dirty improvement until someone has time to figure out a second fallback mechanism using Chris's suggestion:
I'm on vacation with a slow laptop but I will aim to put up a PR in a few weeks if nobody gets around to it earlier. |
This PR is an incremental improvement to `ls` when it encounters 'illegal' file paths on Windows. Related: #7869 ## Context We have trouble with filenames that Windows doesn't like, for example [files with a `.` at the end of their name](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions). To make a long story short, the Rust stdlib and several Win32 APIs will choke if asked to do something with an illegal filepath. This is a problem because files with illegal names can be created via other means (like `touch foo.` in MINGW bash). Previously `ls` would fail completely in a directory with a bad file, which isn't great. After this PR, bad files get included in `ls` results but without any metadata columns. This is not quite where we want to be — eventually we want to be able to display file metadata for _all_ files (even naughty ones) — but it's an improvement on the status quo. ### Before  ### After  ## Future work Try the workarounds @ChrisDenton suggested: #7869 (comment) Some info on verbatim paths: https://users.rust-lang.org/t/understanding-windows-paths/58583 ## Testing I tried to write a test for this, but it looks like our testing sandbox can't create files with illegal filenames.😔 Here's the code in case it proves useful someday: ```rust /// Windows doesn't like certain file names, like file names ending with a period: /// https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions /// However, those files can still be created with tools like MINGW bash. /// We may not be able to get full metadata for those files, but we should test that we can at least include them in ls results #[test] #[cfg(windows)] fn can_list_illegal_files() { Playground::setup("ls_test_all_columns", |dirs, sandbox| { sandbox.with_files(vec![ EmptyFile("foo"), EmptyFile("bar."), EmptyFile("baz"), ]); let actual = nu!( cwd: dirs.test(), "ls | length" ); assert_eq!(actual.out, "3"); let actual = nu!( cwd: dirs.test(), "ls" ); assert_eq!(actual.out, "1"); let actual = nu!( cwd: dirs.test(), "ls | where {|f| $f.name | str ends-with 'bar.'} | length" ); assert_eq!(actual.out, "1"); }) } ```
|
I've just merged a fix that handles this a little better: #7999
Eventually we'd like to get to a place where Nu can read the metadata of files with 'illegal' names too. Chris's suggestion of verbatim paths seems like the most promising approach, IMO. Might as well leave this issue open until we get around to the full solution. |
Describe the bug
While the Win32 API doesn't allow files or folders with trailing dots, the filesystems do allow it and programs do and can create files with trailing dots or spaces.
If this happens nushell reports the following
Error: nu::shell::error_reading_file (link)
How to reproduce
In Bash on Windows
touch "foo."
In Nushell on Windows
ls
Expected behavior
I expected nu to list the directory regardless of files that end in spaces or dots.... just like bash does.
Screenshots
No response
Configuration
Additional context
No response
The text was updated successfully, but these errors were encountered: