> > > I use long pathnames and filenames in my work constantly. I
> have
> > > already set Windows to support long file paths so that isn't the
> > > problem.
> > >
> > > When I go to open a file that has a long path greater than 260
> > > characters, Ztree chokes and gives me the irritating error from
> > Windows-
> > > cannot find file and the subsequent error Unable to open file error
> > 1223.
> > > I say irritating because I have to close out two error messages
> not
> > just
> > > one.
> >
> > Is there a chance this Windows long names setting will become the
> > default? It has the potential to mess badly with Ztree's usability.
> It
> > might be worth recording it as a bug under the post for the latest
> zeta.
> > I see no length limit mentioned in the help file, so that's what it
> is.
>
> I am not understanding what you are referring to as a bug. If I were
> to guess, let me respond by saying that Windows OS may make this the
> default in the future - who knows - that fact that Windows Home still has
> to turn it on via the Registry is probably holding this back- but all it
> takes is another 'major' update to change all that. There are,
> however, many people who do have this enabled - Home or Pro. It just
> makes sense. It is just another option. Heck I also have shortnames
> turned on as well.
>
> If you are saying that Ztree would make it a default - why? when all
> users would have to do is turn it in or off via the Config. What would be
> the big deal?
>
> If you are stating that the Ztree help should mention the limitation
> rather than do something about it - well, I don't support that the way
> you wrote it as a 'bug'. That would be the same as saying Ztree would
> never support it - case closed. All people who want it - look elsewhere
> - not welcome here. I am, however, all for the help stating that at the
> moment the limitation is 260 characters under the Windows old API
> restriction of MAX_PATH.
>
> Why would it affect Ztree's usability? Your statement doesn't make
> sense - and again, I apologize ahead of time if I am misunderstanding
> your statement. But if not, - just another option - turn on, turn off.
> I remember when the Dir mode was such a big deal in the forums - and if I
> am not mistaken there were some for and against this as well. Kim did
> finally implement this, and it took some work on Kim's part to get it
> right - in fact he is still working on it. But if you don't want to use
> it - don't hit the 'w' command to turn it on. But I bet that most
> people do use it - even the original naysayers.
>
> I'm sure that involved re-writing a lot of code.
>
> By the way this is just a discussion. I am not looking to ruffle
> anyone's feathers over this.
>
> Hi Kim - I wish you would weigh in on this - If I am wrong, then I am
> wrong. I am not looking to cause problems by making a request.


My view this is a ZEP not a bug, i.e.

========
ZEP
Please update ZTree so that it becomes longPathAware and so can access long paths on systems where this policy is enabled

Computer Configuration > Administrative Templates > System > Filesystem > Enable Win32 long paths

See https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file
========


For people who need the old behavior they could edit the longPathAware setting in the manifest.

There will be issues calling external utilities, for those I guess falling back to the shortname would be the first step, and we might need a new F9 Directive to switch to shortnames when the path hits MAX_PATH. Both of those assume that shortname generation is enabled.


Thanks
Ben