> > I have no doubt about what you say in terms of some older 32 bit
> programs,
> > but I have not experienced this under 64 bit OS.
>
> I don't run Win10 with long path names enabled by default, but last I
> checked it in a virtual machine, Explorer still had various problems with
> paths longer than 260 characters. A quick search for `windows 10
> "explorer" "longPathAware"` brings up many recent results that seem
> to confirm that the problems still exist. One thing I checked first hand
> on my Win10.1909 machine is that Explorer.exe has neither an embedded
> manifest nor a separate .manifest file declaring it to be
> "longPathAware". This means that, even if you have long paths enabled
> at the OS level, Windows does not recognize Explorer as supporting paths
> longer than 260 characters, and therefore falls back to the
> pre-Win10.1607 behavior.
>
> This does not necessarily mean that Explorer fails on *all* paths
> longer than 260 characters. What it means, however, is that as far as
> Explorer is concerned nothing changed since the Win10.1607 update.
> Whatever support Explorer may have had for long paths before, that still
> exists now, but it does not support or take advantage of the extended
> limits available at the OS level since Win10.1607.
>
> > If it were true that turning it on did something permanent, Microsoft
> would have
> > removed the option, but if anything, it has had stronger support.
> They moved the
> > option from it's original setting in Group Policy but that's about
> it.
>
> IMHO it is more telling what they did *not* do. The manifest
> requirement is still in place for an app to be eligible to take advantage
> of the extended path limits. Otherwise, unleashing >260 char paths onto
> unsuspecting and unprepared apps would have wreaked complete havoc. While
> necessary, this also means that each individual app will need to be
> updated and marked "longPathAware" before they can take advantage of
> the extended limits. Just because it's turned on at the OS level
> doesn't mean it's available to everything that's running.
>
> Cheers,
> Liviu

Oh yes I definitely agree. I think I said that in an earlier post that although the OS supports it, 3rd party utilities need to have the support added individually. In further testing I am finding out just how the files are being passed to these utilities via Explorer - as shortnames - at least that is my findings so far. That would explain why a program from 2004 is able to open these files indirectly. It also may be a way for the support to be implemented in Ztree somewhat directly without directly supporting LFNs and requiring major rewrite - I refer you to Laurent's suggestion but I would think it would be better as some option of Alt O. Anyway the discussion goes on.