Win32 SetCurrentDirectory() function failing to change current directory to a path with dot at the end, resulting GetLastError 2 (The system cannot find the file specified.).
What's wrong?
File names are not allowed to end in dots, and the behaviour is not guaranteed if they do.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#naming_conventions
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.
Related
I'm developing a file manager application, and noticed that some functions don't work with an existing folder that ends with a space symbol. E. g. "E:\1 \". This isn't specific to this particular folder, but indeed to any one with a space as the last character of the folder's name. For such folders, SHParseDisplayName returns ERROR_FILE_NOT_FOUND.
I'm calling SHParseDisplayName like so from C++:
ITEMIDLIST* idPtr = nullptr;
const auto result = SHParseDisplayName(L"E:\\1 \\", nullptr, &idPtr, 0, nullptr);
The documentation doesn't specify any edge cases, nor any ways in which the input path should be pre-processed. Regardless, I tried decorating it with quotes:
SHParseDisplayName(L"\"E:\\1 \\\"", nullptr, &idPtr, 0, nullptr);
And supplying a UNC path:
SHParseDisplayName(L"\\\\?\\E:\\1 \\", nullptr, &idPtr, 0, nullptr);
Both of which results in E_INVALIDARG.
Of note: SHParseDisplayName does work properly for items nested inside such a folder, e. g. L"E:\\1 \\some_internal_folder\\", just not the folder whose name ends with a space itself.
Is there any workaround? Windows Explorer seems to work just fine with such folders (as one would expect).
Also, SHParseDisplayName isn't the only Windows API function that fails for such folders. Another example of the same behavior is ILCreateFromPathW.
File and Folder names that begin or end with the ASCII Space (0x20)
will be saved without these characters. File and Folder names that end
with the ASCII Period (0x2E) character will also be saved without this
character. All other trailing or leading whitespace characters are
retained.
The Win32 API (CreateFile, FindFirstFile, etc.) uses a direct method
to enumerate the files and folders on a local or remote file system.
All files and folders are discoverable regardless of the inclusion or
location of whitespace characters.
Refer to "Support for Whitespace characters in File and Folder names"
And blog "MS-DOS also allowed spaces in file names, although vanishingly few programs knew how to access them.
So for existing files/folders with space at the end of names, either use Win32 API (CreateFile, FindFirstFile, etc.) or replace them with a new name without trailing or leading whitespace characters.
I'm working on a personal project that I was trying to solve via canonicalizing a relative path in Rust. However, whenever I do so, the new path gets prefixed with a strange \\?\ sequence. For example, something as simple as:
let p = fs::canonicalize(".").unwrap();
println!("{}", p.display());
will result in something like the following output:
\\?\C:\Users\[...]\rustprojects\projectname
This isn't a particular problem because I can accomplish what I'm attempting in other ways. However, it seems like odd behavior, especially if you are going to use the string form of the path in some way that requires accuracy. Why is this sequence of characters prepending the result, and how can I avoid it?
The \\?\ prefix tells Windows to treat the path as is, i.e. it disables the special meaning of . and .., special device names like CON are not interpreted and the path is assumed to be absolute. It also enables using paths up to 32,767 characters (UTF-16 code units), whereas otherwise the limit is 260 (unless you're on Windows 10, version 1607 or later, and your application opts in to longer paths).
Therefore, the \\?\ prefix ensures that you'll get a usable path; removing that prefix may yield a path that is unusable or that resolves to a different file! As such, I would recommend that you keep that prefix in your paths.
File.directory?(ENV["HOME"])
returns false because ENV["HOME"] contains path with Russian words, like:
c:/Users/Администратор
How do I solve it?
You seem to be on Windows. Windows has the oddity, that upper- and lowercase file names are not distinguished (i.e. Windows remembers the case of the letters, when the entry is created, but it ignores case, when a filename is used). Ruby tries to mimic this, but I don't know whether it is able to to this "case-insensitivity" with cyrillic characters. Could it be that the directory had been created in a different spelling (with regard to upper/lower case), than it is stored in the ENV hash?
I would proceed as follows: From an irb shell, do a
Dir['c:/Users']
You should see the entries in the "correct" spelling. Does it exactly match the content of ENV['HOME']? If you use copy and paste from this output, and ask (again in the irb shell) for File.directory?('....'), does it evaluate to true then?
I have HTML input I am supposed to extract 2 Strings of, build a document title string of type <string 1> / <string 2, create a PDF from the source on the users mac desktop and name it as described.
I do know that a slash in a document name is not such a brilliant idea but this is what I am asked to do.
Problem is: the forward slash is interpreted as a folder on the mac and not as part of the documents name which means QPainter fails to print to PDF because it interpretes string1 / being a folder that doesn't exist.
BTW when omitting the / my code is working fine.
How am I supposed to escape the /?
Here's the string building logic:
QString docTitle;
docTitle.append(string1);
docTitle.append(" / ");
docTitle.append(string2);
On OS X, the name of a file at the level of the APIs is different from the display name that is shown to the user in the Finder, open and save panels, etc.
At the level of the APIs, file names simply can't contain slashes. They are reserved for separating names within a path. There's no form of escaping or quoting to allow it.
However, you can create a file whose name will be displayed with a slash in the UI.
Basically, the slash (/) and colon (:) characters swap roles. The display names of files can't include a colon, because it's reserved. (This is a holdover of the old HFS file system used in Classic Mac OS.) So, one aspect of the conversion from names-in-the-APIs to display names is to convert from colons to slashes. Thus, if you want a file whose display name has a slash, you actually use a colon.
A file whose name as per the APIs is "Important legal document 06:13:2015.pdf" will be displayed in the UI as "Important legal document 06/13/2015.pdf". Likewise, if a user names a file in a save dialog or in the Finder as "Important legal document 06/13/2015.pdf", it will end up with a name which, when observed via the APIs, will be "Important legal document 06:13:2015.pdf".
I am trying to use Windows API functions compatible with Windows XP and up to find the target of a junction or symbolic link. I am using CreateFile to get a handle to the reparse point, then DeviceIoControl with the FSCTL_GET_REPARSE_POINT flag to read the reparse data into a REPARSE_DATA_BUFFER. Then, I use the offsets and lengths in the buffer to extract the SubstituteName and PrintName strings.
In Windows 8, extracting the PrintName works perfectly, giving me a normal path (ie c:\filename.ext), but in XP the PrintName section of the REPARSE_DATA_BUFFER seems to always have a length of 0, leaving me with an empty string.
Using the SubsituteName seems to work in both, but I always end up with a prefix of \??\ on the beginning of the file path (ie \??\c:\filename.ext). (as a side note, fsutil reparsepoint query shows the \??\ prefix as well).
I've read through much of the documentation on MSDN, but I can't find any explanation of this prefix. If the prefix is guaranteed to begin every SubstituteName, then I can just exclude the first four characters when I copy the file path from the buffer, but I'm not sure that this is the case. I would love to know if the "\??\" prefix appears in the SubstituteName for all Microsoft reparse points and why.
The Windows kernel has a "DOS Devices namespace" \DosDevices\ which is basically where anything you can open with CreateFile resides. (QueryDosDevice is a function which gives you all the members of that namespace.)
Because it's such a commonly used path, \??\ also redirects to that namespace. So, to the kernel, the path C:\Windows is invalid -- it should really be written as something like \??\C:\Windows. That's where this notation comes from.
The \??\ prefix means the path is not parsed. It is not guaranteed on every name, so you will have to look for the prefix on a per-name basis and skip it if present.
Update: I could not find any definitive documentation explaining exactly that \??\ actually represents, but here are some links that mention the \??\ prefix in action:
http://www.flexhex.com/docs/articles/hard-links.phtml
Note that szTarget string must contain the path prefixed with the "non-parsed" prefix "\??\", and terminated with the backslash character, for example "\??\C:\Some Dir\".
http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/908b3927-1ee9-4e03-9922-b4fd49fc51a6
http://mjunction.googlecode.com/svn-history/r5/trunk/MJunction/MJunction/JunctionPoint.cs
This prefix indicates to NTFS that the path is to be treated as a non-interpreted path in the virtual file system.
Private Const NonInterpretedPathPrefix As String = "\??\"