PhantomDeejay
Don Moir wrote :
2) In Win7 and up (maybe Vista as well) you can use paths up to 32767 characters, You must prepend \\?\ to the path and you must use unicode for the paths and use only unicode path functions. Not all path functions support the \\?\ but most do.
2) In Win7 and up (maybe Vista as well) you can use paths up to 32767 characters, You must prepend \\?\ to the path and you must use unicode for the paths and use only unicode path functions. Not all path functions support the \\?\ but most do.
Still, most applications (including Windows Explorer) fail to read paths longer than 260 chars.
It's only under Windows 10 with a hotfix applied that applications can use the "standard" way and read more than 260 chars.
Still for Windows 7 & 8/8.1 Microsoft suggests that you should avoid using "\\?\" method and that you should better mount a folder of the path as a new folder in order to shorten the path.
Generally speaking I don't see the reason why a programmer should mess with all that fuzz when the OS itself is "half capable" to support 260+ chars long names.
Microsoft decided to fix this only under Windows 10, and only with a hotfix and .NET 4.6.2
Windows 10 Anniversary update released one year ago included the hotfix, but end users still have to tweak their registry manually or set a group policy in order to get support for 260+ chars on their OS.
Quote :
Note that these examples are intended for use with the Windows API functions and do not all necessarily work with Windows shell applications such as Windows Explorer. For this reason there is a wider range of possible paths than is usually available from Windows shell applications, and Windows applications that take advantage of this can be developed using these namespace conventions.
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. For example, if the file system supports large paths and file names, you can exceed the MAX_PATH limits that are otherwise enforced by the Windows APIs. For more information about the normal maximum path limitation, see the previous section Maximum Path Length Limitation.
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. For example, if the file system supports large paths and file names, you can exceed the MAX_PATH limits that are otherwise enforced by the Windows APIs. For more information about the normal maximum path limitation, see the previous section Maximum Path Length Limitation.
Source: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
Mensajes Mon 13 Nov 17 @ 7:25 am
Don Moir
Definitely a programmer internal thing. I tried it years ago for some special encoding that the user need not know about or view. I ended up making it shorter to conform though. If a folder does become greater than 260 thru some series of events, then it is possible to open from a program using .//?/ but the user should be warned via the program via something meaningful.
You can't always view something from a users perspective and decide what others should do based on that. Some work arounds can be strange.
You can't always view something from a users perspective and decide what others should do based on that. Some work arounds can be strange.
Mensajes Mon 13 Nov 17 @ 9:24 am
PhantomDeejay
My point is that even if VirtualDJ was using WIN32 API to do file operations with "\\?\", the user would still had issues with the OS itself.
E.G: He would not be able to copy/move or even open his files exceeding the 260 chars limit because Windows Explorer DOES NOT use this API.
Therefore it's better to advise the user to stay under this limit. Even in Windows 10.
Until Microsoft makes Windows 10 "default" behavior to support 260+ chars, it's strongly advised to stay UNDER that limit.
E.G: He would not be able to copy/move or even open his files exceeding the 260 chars limit because Windows Explorer DOES NOT use this API.
Therefore it's better to advise the user to stay under this limit. Even in Windows 10.
Until Microsoft makes Windows 10 "default" behavior to support 260+ chars, it's strongly advised to stay UNDER that limit.
Mensajes Mon 13 Nov 17 @ 10:42 am
Adion
Worked fine in Windows 10 for me without making any changes actually.
Explorer will by default not allow you to rename a file so that the path becomes more than 260 characters, but once you have such file they play and work fine.
Anyway, partial fix for this issue should be in next build. Full support for over 260 characters will be available once XP support is dropped. (since the folder enumeration api that can return more than 260 characters was not available on xp)
Explorer will by default not allow you to rename a file so that the path becomes more than 260 characters, but once you have such file they play and work fine.
Anyway, partial fix for this issue should be in next build. Full support for over 260 characters will be available once XP support is dropped. (since the folder enumeration api that can return more than 260 characters was not available on xp)
Mensajes Mon 13 Nov 17 @ 10:52 am
Don Moir
I don't know how you came up with that info was for an end user. I said:
You must prepend \\?\ to the path and you must use unicode for the paths and use only unicode path functions.
Which implies it is programmer information and was directed at Adion. I don't think most end users would know what unicode path functions are. So not directed at end users.
You must prepend \\?\ to the path and you must use unicode for the paths and use only unicode path functions.
Which implies it is programmer information and was directed at Adion. I don't think most end users would know what unicode path functions are. So not directed at end users.
Mensajes Mon 13 Nov 17 @ 11:13 am
RENZDJ13
Thank you guys for your input. I really appreciate everything. I tried Serato (fully licensed included in my controller but not fan of it) and it's really works - no problem at all. I am just saying. Thanks again guys. I cannot wait for the next build.
Mensajes Sat 18 Nov 17 @ 8:52 am
RENZDJ13
Thank you guys for helping me. I think the last update fixed most of my issues. Again thank you so much and have a wonderful Christmas and Prosperous New Year to everyone!!!
Mensajes Tue 19 Dec 17 @ 4:29 am