[Lazarus] FileExistsUTF8 and long paths

[Jürgen Hestermann]

Am 2016-01-17 um 12:42 schrieb Bart:
 > On 1/16/16, Jürgen Hestermann <juergen.hestermann at gmx.de> wrote:
 >> Well, at least when the path is too long (length(FileName>MAXPATH))
 >> it can prepend \\?\ because it will fail without it anyway.
 > That won't do for the same reasons as explained above.
 > Say you have a directory: c:\maxpathchars\1\2\3\
 > Now cehcking for ..\..\foobar will still fail if
 > c:\maxpathchars\1\foorbar exists, unless you have a folder in
 > c:\maxpathchars\1\2\3\ that actually has the name  '..' etc.
 > I.o.w expanding the filename cannot be done anymore.

Yes, that's true.
Additional checks (i.e. for dots) are needed
but I think it should be possible to find out
when a path is:

1. not relative and
2. without forward slashes and
3. too long to be resolved without prepended \\?\

so that adding \\?\ would make the request successful
when it otherwise would fail.


 > Note that even Windows itself (at least windows explorer) cannot handle this.

Windows (the API) *can* handle this, only explorer can't.
I have written a file manager that has no problem to copy/move/rename etc.
files with paths of arbitrary length.
Of course, many special things (like deleting to recycle bin and setting
current directory) do not work with such long paths,
but at least those things that work should be made functional.


 > I once unzipped a file with such a filename (produced on linux of course).
 > It unzipped well and FileexistsUtf8('\\?\realfilename) worked well.
 > (Testing this was the reason I did this.)
 > After that windows was unable to remove the file in question.
 > I tried various tools for that, icluding rm - R *.
 > No such luck.

It seems that the unzip tool you used *was* able to handle long paths.
In such cases you can use more appropiate file managers like Total Commander or
Ztree that have larger limits than 255 (but still Ztree has a limit of 400 and
Total commander of 1000 character which I don't understand).
When using the W functions the limit is near 32000 so why don't they all support this?
Strange.


 > To me it looks like a rather odd design desicion by MS have a MAXPATH
 > but then have obscure ways to circumvent that.

Yes, again it is very bad design from MS that all (Windows users) have to live with.
But we should not make it worse than it already is.
So if the W functions support long paths we should support this too.


 > AFACS it cannot be resolved/fixed in a manner that will not break
 > backwards compatibility.

I think it is possible (see above).
You only need to find out the exact limitations and detect them before adding \\?\


 > Further more: this is not something that belongs to Lazarus, but to fpc.

I am not sure. I thought FileExistsUTF8 is part of Lazarus, not Free Pascal.


 >> I did not find any comments that mentions long paths
 > You need new glasses then ;-)
 > === code ==
 >   //if Filename uses ExtendedLengthPath scheme then it cannot be expanded
 >   //AND it should not be altered by ForcePathDelims or ResolveDots
 >   //See: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx
 >   if (Length(Fn) > 3) and (Fn[1] = PathDelim) and (Fn[2] = PathDelim) and
 >      (Fn[3] = '?') and (Fn[4] = PathDelim) //Do NOT use
 > AllowDirectorySeparators here!
 >      then Exit;
 > === end code ===

I have read this but how is this related to \\?\ and long paths?
What is ExtendedLengthPath scheme?
I don't see any information about W functions and \\?\ prefix.