Strange behavior from .NET regarding file paths

问题:

I couldn't find any information on this through professor Google, so here I am. Take the given path name and paste it into Windows Explorer. I stumbled across this after discovering bug in my code that generated the paths with an extra '.' in the path name before a directory \ separator...

@"C:\\pathto.\file.ext"

In code, .NET will accept the path when calling File.Create and a file will be generated, but at this path:

@"C:\\pathto\file.ext"

Copying C:\\pathto.\file.ext into Windows Explorer's address bar and watch the '.' disappear and take you to C:\\pathto\file.ext

Is it normal behavior for .NET and Windows to It's not causing an issue because the '.' is being removed by both .NET and Windows when passed into file operations. The real issue is that all the files in the DB have filenames with a '.\', but exists in paths that do not have a '.\'... and File.Exists() works too, although the path is not the 'real' physical location...

What's going on here?

回答1:

This is a "feature" of the Windows file system. MSDN:

Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not. However, it is acceptable to specify a period as the first character of a name. For example, ".temp".

回答2:

All normal Windows APIs ignore/remove trailing dots in the file/folder names when regular path is passed in.

If you really need support for trailing dot you need to use "\\?\" prefixed paths and interop all calls yourself (as .Net does not support this file format). See MSDN: Naming Files, Paths, and Namespaces, How to delete a folder that name ended with a dot (".")? and You cannot delete a file or a folder on an NTFS file system volume for more info.

Here is related question showing how to PInvoke function that accepts long file path: c# call Win32 API for long file paths?