Client for Open Enterprise Server 2 SP7 removed limits within the kernel-mode drivers which prevented specifying paths beyond the Microsoft MAX_PATH limit of 260 characters.
Salvage, Purge, and OES Copy features within the Client for Open Enterprise Server 2 SP7 are still limited to MAX_PATH.
Windows applications that are designed to handle paths longer than MAX_PATH can now specify such paths on NCP-based mapped drives and NCP-based UNC paths, in conjunction with Microsoft's LongPathsEnabled policy in Windows.
Windows applications that are not designed to handle paths longer than MAX_PATH cannot specify such paths, regardless of the Microsoft LongPathsEnabled policy or the Client for Open Enterprise Server changes.
If there are issues in handling longer paths with Microsoft Windows on NTFS or CIFS-based paths, such issues persist when specifying longer paths on NCP-based paths too.
Client for Open Enterprise Server 2 SP6 or earlier was designed to support paths up to the Microsoft Windows MAX_PATH limit of around 260 characters. This included the length needed to specify the server and volume the path existed on. So the actual path length supported on a mapped drive would be notably less than 260 characters. Within the Client for Open Enterprise Server, both the kernel-mode drivers supporting the file system access and the user-mode code supporting the network provider and shell extensions were all designed around the Windows MAX_PATH limit.
Beginning with Client for Open Enterprise Server 2 SP7, the client-side kernel-mode driver limitations are eliminated. Such that the Microsoft Windows file system APIs such as CreateFile, RenameFile, DeleteFile, and so on can successfully specify paths longer than the traditional MAX_PATH limit even when using NCP-based paths.
Which in turn means that Windows applications specifically designed to take advantage of paths longer than the MAX_PATH limit can now specify such paths even when working with NCP-based drive letter mappings or UNC paths. The longer path requests being made through Microsoft file system APIs will now be passed on to the OES NCP server.
An application which was not designed to handle or support paths beyond the traditional Microsoft Windows MAX_PATH limit will still be unable to do so regardless of whether the path is NCP-based or not. Such support cannot be “forced” either, through addition of the Microsoft “longPathAware” manifest. If the existing application code was not designed to allocate more than MAX_PATH for storing and manipulating paths, the forced addition of the “longPathAware” manifest would only allow paths longer than MAX_PATH to be copied into memory space which is still limited to MAX_PATH.
NOTE:The path length which is ultimately successful remains up to the Open Enterprise Server NCP server, and may vary according to UTF-8 encoding and what Unicode characters are actually present in the path.
With Client for Open Enterprise Server 2 SP7 release, the Client specific shell extension functions such as Salvage, Purge, and OES Copy are not yet redesigned to handle specifying paths longer than MAX_PATH. These client features are not available on paths which exceed the MAX_PATH limit, or may skip presenting and including files and folders which would require more than MAX_PATH length to successfully handle.
Also note that the removal of these MAX_PATH limits within the Client kernel-mode drivers does not mean that all the existing Windows applications can now access longer paths. It does not even mean that all of the applications included with Microsoft Windows itself works successfully with longer paths, either. For example, Microsoft's File Explorer, even on Windows 11, does not support paths beyond MAX_PATH limits without issue.
Removing these MAX_PATH limits from the Client kernel-mode code is the needed step towards enabling longer path support for Windows applications over NCP. For more information on the changes to Maximum Path Length Limitation that Microsoft introduced in Windows 10, see Microsoft documentation.
The longPathAware manifest that Microsoft describes is added by the publisher of the application, only after that publisher has redesigned any parts of the application which are necessary to handle long paths beyond the MAX_PATH limit. The longPathAware manifest is the signal to Microsoft Windows that it would be safe to return a path longer than MAX_PATH to this application, because the application has been suitably designed or re-designed to handle such paths without crashing or overwriting memory.
When encountering or testing long path behaviors with the Client for Open Enterprise Server, it may be necessary to determine whether the application works successfully with long paths using a local NTFS-based path, or a CIFS-based network share. Since plenty of application still do present such issues and limitations, in spite of the ability to specify longer NCP-based paths is now possible.