SetCurrentDirectory path limit

According to MSDN docs for SetCurrentDirectory ( path must be MAX_PATH -2 or less bytes (without trailing '\') MAX_PATH-1 if '\' is included.

I have a situation where I have a path (Windows 10) that is MAX_PATH -1 without trailing '\'.

Question if the OS allows this path - how do I SetCurrentDirectory to it ?
LVL 70
Julian HansenAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Farzad AkbarnejadDeveloperCommented:
If the OS (Windows 10) allows you can do set it. For example Windows 10 explorer use same logic that your C++ program running on Windows use.

If the OS (Windows 10) allows you can do set it.
that is not true. windows allows path lengths up to 1024 what is nearly double of MAX_PATH, which currently is 260. MAX_PATH-1 however is limitation of most api functions and if you pass zero terminated path strings longer than this limitation, the function either would fail or - worse - write beyond array boundaries or might skip the termination and cut the path at the last character.

see for more information.

Julian HansenAuthor Commented:
So, is the solution then that you cannot use SetCurrentDirectory if you want to change path to one that is longer than 258 chars? Seems like a bit of an oversight.

_chdir has the same limitation.

Anyone have any ideas about how to programmatically change directory into a path > 258?
Learn Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

it is possible by using the \\?\ prefix as described in the link i posted:

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".
Note  The maximum path of 32,767 characters is approximate, because the "\\?\" prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length.

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. Because you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters.

There is no need to perform any Unicode normalization on path and file name strings for use by the Windows file I/O API functions because the file system treats path and file names as an opaque sequence of WCHARs. Any normalization that your application requires should be performed with this in mind, external of any calls to related Windows file I/O API functions.

When using an API to create a directory, the specified path cannot be so long that you cannot append an 8.3 file name (that is, the directory name cannot exceed MAX_PATH minus 12).

The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface is not able to interpret properly.

another way out is to use 8.3 short name for each folder in the path. winapi functions like FindFile additionally provide the short names.

i personally don't think that file paths with huge lengths should be supported by user applications. it doesn't help if a few programs can handle that, and finally the user can't print it or can't add it to their mail or link. i think it is better to refuse the file in the first case.

i remember a case where a user took the whole contents of a text message to build the filename and the file itself was empty. one of these files was shown (partly) in the explorer but all actions of the right-click menu failed with "file not found".


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Julian HansenAuthor Commented:
Tried it with the \\?\ prefix - same problem - choking on the path 259 bytes in length.

Going to try the UniCode version to see if that is better - the docs seem to indicate that it should work. I will need to convert the routine to wide char - will check back when that is done.
Julian HansenAuthor Commented:
Thanks for the input pushed me in the right direction.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.