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

[Alistair Grant]

Hi Tobias & Tim,

On Wed, Dec 19, 2018 at 10:52:11AM -0800, tim Rowledge wrote:
>  
> 
> I think all I can really do is offer my sympathies at this point; I remember with shudders that similar problems of different rules for different volumes/fstypes on Win/NT plagued me when I rewrote the filename classes for VW back in '94 or so.

Thanks :-)

But VW did (still does?) have quite a nice model for the file system.  
It didn't take much for me to adapt it to VMS, which uses a somewhat 
different naming convention to Windows and Unix.  This was around about 
the same time - VW2.5.



On Wed, Dec 19, 2018 at 08:00:39PM +0100, Tobias Pape wrote:
>  
> 
> > On 19.12.2018, at 19:36, Alistair Grant <akgrant0710 at gmail.com> wrote:
> > 
> > 
> > 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

Thanks for this!  Writing FileAttributesPlugin is the first time I've
done any C programming on Windows and this has been useful in
understanding the path peculiarities on Windows.


> 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???

As mentioned above, this is used while iterating over directories, so
the full path length isn't known in advance.  I guess it would be
possible to reallocate the space for every file, but that feels
inefficient.

In fact it raises something I've been wondering about:

My current approach does allocate memory that mostly isn't used.  Most
of the time this is on the stack, so the computational cost of
allocation is relatively cheap.

The approach of calling MultiByteToWideChar to determine the length and
then allocate the appropriate amount of memory means that the system has
to decode the entire UTF8 path to calculate the buffer size.

Does anyone have a sense of the overall performance comparison between
the two approaches?  I would guess that there isn't much in it.

Cheers,
Alistair