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

Alistair Grant akgrant0710 at gmail.com
Wed Dec 19 18:00:18 UTC 2018

Hi Tim,

On Wed, 19 Dec 2018 at 18:38, tim Rowledge <tim at rowledge.org> wrote:
> > On 2018-12-18, at 10:55 PM, Alistair Grant <akgrant0710 at gmail.com> wrote:
> > There are two structures being allocated.  The one you provided the
> > code for is small - an integer plus a pointer.  The other one, which
> > has enough room for any path is the big one.  It holds the path in
> > UTF8 (as passed from the image) and in the platform's native format,
> > which for Windows is 32K 16 bit words.
> 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.

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):


Another short path:


is also fine.  A long path such as:

C:\aaa\<b repeated 140 times>\<c repeated 140 times>\abc.txt

works.  But:

C:\aaa\<b repeated 140 times>\<d repeated 140 times>\..\<c repeated
140 times>\abc.txt

fails with an invalid path name.

I'm open to dropping Windows as a supported platform. :-)


More information about the Vm-dev mailing list