[Issue 8967] dirEntries throws when encountering a "long path" on windows

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Mar 17 21:18:40 PDT 2014


https://d.puremagic.com/issues/show_bug.cgi?id=8967



--- Comment #6 from Vladimir Panteleev <thecybershadow at gmail.com> 2014-03-18 06:18:30 EET ---
(In reply to comment #5)
> 1. The "\\?\" prefix can also be used with paths constructed according to the
> universal naming convention (UNC). To specify such a path using UNC, use the
> "\\?\UNC\" prefix. For example, "\\?\UNC\server\share", where "server" is the
> name of the computer and "share" is the name of the shared folder. These
> prefixes are not used as part of the path itself. They indicate that the path
> should be passed to the system with minimal modification, which means that you
> cannot use forward slashes to represent path separators, or a period to
> represent the current directory, or double dots to represent the parent
> directory.

OK, so special case if the path starts with \\ but not \\?\

> 2. Because you cannot use the "\\?\" prefix with a relative path, relative
> paths are always limited to a total of MAX_PATH characters.

Absolute path as mentioned earlier

> 3. For file I/O, the "\\?\" prefix to a path string tells the Windows APIs to
> disable all string parsing and to send the string that follows it straight to
> the file system.

Does not apply on its own

> 4. Because it turns off automatic expansion of the path string, the "\\?\"
> prefix also allows the use of ".." and "." in the path names, which can be
> useful if you are attempting to perform operations on a file with these
> otherwise reserved relative path specifiers as part of the fully qualified
> path.

Path normalization as mentioned earlier

> 5. Many but not all file I/O APIs support "\\?\"; you should look at the
> reference topic for each API to be sure.

I don't see this as a concern. D unit tests will reveal any Windows APIs that
don't support this syntax

> 6. The "\\.\" prefix will access the Win32 device namespace instead of the
> Win32 file namespace.

Does not apply. Win32 devices are akin to Posix /dev/ and are rarely accessed
directly

> 7. If you're working with Windows API functions, you should use the "\\.\"
> prefix to access devices only and not files.

Same as above, does not apply

> 8. This was accomplished by adding the symlink named "GLOBALROOT" to the Win32
> namespace, which you can see in the "Global??" subdirectory of the WinObj
> browser tool previously discussed, and can access via the path
> "\\?\GLOBALROOT". This prefix ensures that the path following it looks in the
> true root path of the system object manager and not a session-dependent path.

Same as above, does not apply

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list