> I have been investigating the implications of "resizing window via
> dragging frame edge ", so I have been pushing the limits, I will post
> separately regarding those findings.
>
...
>
> ZEP:
> The ZTree copy file command to use the UNICODE syntax, so that copies
> to destinations that are greater than MAX_PATH succeed.


Whoops, I think I exceeded lpMaximumComponentLength, when I was testing so came to the wrong conclusion.

The original ZEP is retracted:
In ZTree you can copy a file, as long as you keep the filename below lpMaximumComponentLength (255 for NTFS)



Replacement ZEP
ZTree should warn if the target filename is longer than GetVolumeInformation() lpMaximumComponentLength.



But I found some other issues for long paths

1. If you try to create a directory who's path is below the Unicode path limit (~32,767), but is above the ZTree input line limit (512), then you get this "Error: [161] Bad Pathname".
But shouldn't that be a ZTree specific error/warning and not a generic system error?


2. You can create a directory in ZTree that has Alt-Info w/Path: 513
If you have that new directory highlighted in the right-hand pane, and copy a file from the left-hand pane, then the destination to path is missing one character (because of the Input line limit), so you get "Directory does not exist. Make new path?"
I guess an "out by one error" between the memory structures and the input line processing.
Maybe show a ZTree specific error/warning when trying to copy etc. to an over ZTree limits directory.


3. When a path length greater than 402 directory is highlighted in one of the panes, tabbing between the panes can cause the highlighted directory to unexpectedly change.
Could that be caused by the old 400 input line limit constant being left in the code somewhere?
i.e. that code wasn't updated when that input line limit was updated to 512


4. Copying a file to a path length=512 directory, gives "Invalid path\filename - too long [9991]"
I expect another ZTree specific instead of a generic system issue.
Again a ZTree specific error/warning would be better.


5. Files with paths over the ZTree Input line limit (512) are listed but cannot be accessed
In a w/Path: 510 directory, using a powershell script I created a 64 length filename, ZTree can see the file in the file window with size, attribs and date.
But Alt-Info has no info and has "Error: File not found"
Again a ZTree specific error/warning would be better.


General
As people haven’t been complaining of the inability to access files with full paths over the ZTree input line limit of 512, there isn't a great demand to increase the fullpath limit.

I guess the input line limit is used in buffers that are also used to create paths to be passed to API's. If so then if the built path had it's own larger limit, possibly 32K, then it might be possible to support very long paths with very little change to the ZTree code, but to do that the destination directory input fields would also need to use the larger limit.


Ben