Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File.Open mangles path ending in ~.SS #18664

Closed
smbecker opened this issue Sep 22, 2016 · 4 comments
Closed

File.Open mangles path ending in ~.SS #18664

smbecker opened this issue Sep 22, 2016 · 4 comments
Assignees
Milestone

Comments

@smbecker
Copy link

I have a file accessible through \localhost\Test\test.txt.~SS. If I attempt to access that file using File.Open, I get an exception:

Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path 'o\t\Test\test.txt.~SS'.
   at System.IO.Win32FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, FileStream parent)
   at System.IO.Win32FileSystem.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, FileStream parent)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at System.IO.File.Open(String path, FileMode mode)
   at ConsoleApplication.Program.Main(String[] args)

Notice that the path that it is complaining about is mangled from the requested path. I have a repro available here. This works as expected using desktop framework but fails when targeting .NET CoreCLR. It also works as expected if I rename the file to test.txt.~sstmp.

Thoughts?

@smbecker
Copy link
Author

After doing a bit of digging, I found that FileStream resolves the path using Path.GetFullPath. If I pass the in above file name into Path.GetFullPath, it returns the mangled name that is referenced in the above exception.

@smbecker
Copy link
Author

After looking a bit into Path.GetFullName, I would guess that the issue is that the file is incorrectly being handled as a short file name here. Should I close this bug and reopen in that repo?

@stephentoub
Copy link
Member

cc: @JeremyKuhne

@JeremyKuhne JeremyKuhne self-assigned this Sep 22, 2016
@JeremyKuhne
Copy link
Member

Looking into it. We don't utilize the code in CoreCLR from CoreFX, but I'll follow up with that copy as well.

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 2.0.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants