[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] FileAttributesPlugin 2.0.6 (#321)

[Tobias Pape]

> On 19.12.2018, at 19:36, Alistair Grant <akgrant0710 at gmail.com> wrote:
> 
> 
> Hi Tim,
> 
> On Wed, 19 Dec 2018 at 19:13, tim Rowledge <tim at rowledge.org> wrote:
>> 
>>> On 2018-12-19, at 10:00 AM, Alistair Grant <akgrant0710 at gmail.com> wrote:
>>>> 
>>> The whole thing is actually quite a mess, e.g. opening a short path (<
>>> 260 characters) works as expected (this is assuming the files really
>>> do exist in all examples below):
>> 
>> OK, it seems that you have to explicitly enable the longer path lengths and so you may be falling foul of that.
> 
> Yep, that's the long path prefix (\\?\).  Whether you use that or not
> depends on the variant of call you are using, the length of the path
> and the version of Windows you're running.  Paths < MAX_PATH-12 never
> use the LPP.  For longer paths it depends on the call and the version
> of Windows that you are running.
> 
> But the difference isn't that it is a long path, but that the relative
> reference (..) appears in a long path.
> 
> 
>> Supposedly MAX_PATH tells you but I haven't seen anything that tells me if the macro value gets changed if you enable long paths (and indeed, unless it is actually a variable, how could it change). Surely ther must be some variable or call that tells you the correct value; even Microsoft isn't *that* useless.
> 
> The MS documentation says that you need to get the volume information
> to accurately determine the actual maximum path length.  And then it
> is a matter of using calls that support long paths (e.g. the posix
> compliant calls don't) and adding the LPP when required.

I wrote a small helper for that a few moons ago:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/476f70605a0352dd7528d251f7403e9233716cdb/platforms/win32/plugins/FilePlugin/sqWin32File.h#L33

However, I see that struct fapathstruct defines a preallocated winpathLPP of 32768 + 4 WCHARs. I think an approach similar to that above would cut that to just a pointer, right? MultiByteToWideChar tells you how much it needs when you give it a NULL outpointer…


Best regards
	-Tobias

PS: please don't use strcpy/strlen but strnlen and memcpy (like in line 101) :)
> 
> Cheers,
> Alistair