Accessing files with invalid names in Windows

Question

I'm running Windows 7 in a VirtualBox on an OS X 10.8 host. The host has a shared folder with a file named >>>FILE<<< inside. Apparently, OS X itself has no problem with such file names. Unfortunately, I can't seem to open this files in Windows 7 because of the <s and >s in the name. In C, this call fails:

CreateFileW(
    L"\\\\VBOXSVR\\ft1\\>>>FILE<<<",
    GENERIC_READ,
    FILE_SHARE_READ,
    NULL,
    OPEN_EXISTING,
    FILE_ATTRIBUTE_NORMAL,
    NULL
    );

GetLastError returns ERROR_INVALID_NAME (123). If I change the file name into FILE, I get a valid handle and everything is fine.

Is there a known way in Windows to access those files with invalid characters in their names? Supposing a productive environment with no direct write access to the host's file system.

Does the remote file system provide short filenames? If so, you may be able to access the file using it's short name. — Jonathan Potter, Jan 08 '13 at 01:54
@JonathanPotter your idea is good, but no, the file system doesn't support short file names and VirtualBox doesn't share them. That may work with an NTFS volume folder shared on a real network with the proper driver. The short file name would look like `___FIL~1`. — GOTO 0, Jan 08 '13 at 20:00

score 2 · Answer 1 · answered Jan 07 '13 at 22:07

2

@jcophenha's answer was on the right track. However, if you read the page that @jcopenha linked to, it states that the \\?\ prefix is for local paths only. You have to use the \\?\UNC\ prefix instead for UNC paths, eg:

L"\\\\?\\UNC\\VBOXSVR\\ft1\\>>>FILE<<<"

answered Jan 07 '13 at 22:07

Remy Lebeau

555,201
31
458
770

I'm sorry, that doesn't seem to work either. It's frustrating. – GOTO 0 Jan 07 '13 at 22:10
1

If `\\?\UNC\server\share` does not work, then you are out of luck. The remote file needs to be renamed to something that is more cross-platform compatible (or at least have a symbolic link created that maps to the real file internally and is cross-platform accessible). – Remy Lebeau Jan 07 '13 at 22:39
@Remy The problem is that both `<` and `>` are reserved characters. – David Heffernan Jan 07 '13 at 23:22
1

If you read the linked article, the purpose of the `\\?\ ` and `\\?\UNC\ ` prefixes is to turn off parsing, which include ignoring reserved characters. – Remy Lebeau Jan 08 '13 at 03:16

David Heffernan · Answer 2 · 2013-01-07T23:30:55.730

The < and > characters are not allowed to be used in a Windows file name. And so that file cannot be opened under Win32.

The naming conventions documentation lists the following reserved characters:

< (less than)

> (greater than)

: (colon)

" (double quote)

/ (forward slash)

\ (backslash)

| (vertical bar or pipe)

? (question mark)

* (asterisk)

Windows differs significantly in this area from *nix systems. On *nix there are typically no such OS enforced limitations on the characters that can be used in a file. As a friend of mine once discovered when he tried to delete a file named * and suffered the most unfortunate consequences.

Now, it is conceivable that these limitations do not apply when using the native API. You could try and open the file with NtCreateFile. That may just work!

I'm afraid you may be right. `NtCreateFile` didn't help, I could only open the file after stripping away `<` and `>` from the name. Strangely, other forbidden characters like the pipe `|` are unproblematic. — GOTO 0, Jan 08 '13 at 00:42

Accessing files with invalid names in Windows

2 Answers2