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

tim Rowledge tim at rowledge.org
Wed Dec 19 18:13:39 UTC 2018



> On 2018-12-19, at 10:00 AM, Alistair Grant <akgrant0710 at gmail.com> wrote:
>> 
>> Good grief, that's huge. Is there no mechanism for querying the size to allow correct allocation? RISC OS has a number of similar APIs where you basically do
>> val = thingyCall(param1, paramN, 0);
>> allocate(buffer, val);
>> result = thingyCall(param1, paramN, *buffer);
> 
> Not directly.  This is used to iterate over a directory, and of course
> there's no way to know in advance what the longest file name in the
> directory is.

Well that's what the RISC OS approach is explicitly for and as I'm sure you can see it is very useful for this stuff.

> 
> 32K is the maximum path length, I have to admit I'm not sure what the
> maximum file name length is on Windows.  The directory name is known
> in advance, so if the maximum file name length is shorter, the buffer
> size could be reduced.  But it may be different for different file
> systems, so I'm not sure that we can be confident.
> 
> 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.
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.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Logic:   The art of being wrong with confidence...




More information about the Vm-dev mailing list