[8.0ß18x32] Search path not found! error on long net path

[CodeMajster]

"Search path not found!" error is shown when launching file form network path that contains more than 260 characters. Launching the same file from windows explorer works fine. Also, launching files from local NTFS path containing more than 260 characters works as expected. There are no issues moving or copying those files.

I tested all versions from 7.55a and they all have this problem.

[ghisler(Author)]

I have checked that: The Explorer is cheating, it's passing the DOS name to the called program if the name is too long. If you try with a truly long name like e.g.
\\servername\C\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\12345678.123\

with 12345678.123 repeated 20 times, it will fail in Explorer too.

[CodeMajster]

Yes that is true. But this cheat seems to be also implemented in TC for local paths. I know it is not perfect but it works most of the time. Can you implement it for network paths?

Thanks

[Impeeza]

All this behavior is related with Windows File System subsystem, the subsystem only can handle paths 256 characters long, but the folder structure can be longer, by example, if you share a folder in a deep folder structure, for the clients the share folder is the root so it can create 256 characters long new folder, but the file system can't access all the path

[thims]

All this behavior is related with Windows File System subsystem, the subsystem only can handle paths 256 characters long

Are you talking about these 256 chars?

[ghisler(Author)]

Yes that is true. But this cheat seems to be also implemented in TC for local paths. I know it is not perfect but it works most of the time. Can you implement it for network paths?

No, it's not - TC passes the long name with \\?\ prefix to the Windows function ShellExecuteEx, which seems to be able to handle it! But using the \\?\UNC\ prefix doesn't seem to work in ShellExecuteEx...