I've got a bunch of folders that upon trying to browse into them, say ". In Process Monitor, I see that the actual error code is NAME_NOT_FOUND -- but they are present.
chkdskfinds no errors in the filesystem.- Neither are they junctions or symbolic links (checked by installing the Link Shell Extension)
I've noticed that the names have a common trait:
- they all have a dot at the end
- in the past, I experienced the same with file/directories with broken names like in the picture:
What's happening here and how do I fix this?
How to delete a file ending in a dot in Windows 7? offers ways to delete it, but that's not acceptable 'cuz I need the contents.
- Unlike
delsuggested in that question,rename "produces the same" " " "File not found". - Neither
\\?\works (same error).
Answer
Windows API "preprocesses" paths before passing them to the kernel. The documentation on this is sketchy: instead, MSDN lists just the net limitations. In particular:
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.
The Unicode I/O APIs that lift the MAX_PATH limitation seem to skip that preprocessing as well.
So, there are two ways of fixing:
Use a program that uses the Unicode I/O API under the hood. Options include:
Use the 8.3 name to access the file/dir:
>dir /x
<...>58B0~1 Для П.П.
>rename 58B0~1 new_name
Using the "native path" -- \\?\ -- doesn't help here because for some cmd builtins -- at least, dir and rename -- these paths are still subject for the preprocessing:
>dir "\\?\C:\Users\Me\Для П.П."
<...>
Directory of \\?\C:\Users\Me\Для П.П
File Not Found
(note the missing end dot in the output).

No comments:
Post a Comment