[Vm-dev] Re: [Pharo-users] issue with large file path on windows

Ben Coman btc at openinworld.com
Mon Aug 24 17:59:32 UTC 2015

On Mon, Aug 24, 2015 at 8:44 PM, Nicolai Hess <nicolaihess at web.de> wrote:

> 2015-08-24 13:34 GMT+02:00 Henrik Johansen <henrik.s.johansen at veloxit.no>:
>> On 23 Aug 2015, at 6:09 , Nicolai Hess <nicolaihess at web.de> wrote:
>> And If you want to review the changes:
>> https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-long-filename
>> 2015-08-23 13:44 GMT+02:00 Nicolai Hess <nicolaihess at web.de>:
>>> For those who had problems with pharo on windows and github based
>>> repositories,
>>> I built a windows vm with support for long paths:
>>> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=sharing
>>> For browsing directories with large paths (FileList or Inspect),
>>> you may need one additional change in the image (But I am not really
>>> sure about that) :
>>> DiskStore>>initialize
>>>     super initialize.
>>>     maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ].
>>> please test and give feedback.
>>> This wasn't as easy as I thought, and I had to make some more changes
>>> for the file permissions (the stat-functions don't work for files with
>>> long paths).
>>> Please test other file/folder operations.
>> - Is an alloca version really worth it for the potential problems?
> It is what Marcel used for the long path support in the squeak vm (I would
> have copy and paste the whole change, but I couldn't find the appropriate
> change for directory functions).

 "Potential problems" sounded like something interesting I could learn.
Here is a summary...

On the use and abuse of alloca
  * alloca five times faster than malloc (but is that necessary given file
operations likely take longer anyway?)
  * most concerns with alloca no problem here e.g. its a very short
lifespan; the pointer is not returned from the function.

The Perils of alloca()
  * remaining concern is potential stack exhaustion...
     * is MAX_LONG_FILE_PATH=32kB significant today (but also consider
embedded application) ?
     * counter argument, primitive functions are not likely to entered
recursively ?

Microsoft advises alloca [1] deprecated in favour of malloca [2] which
allocates either stack or heap depending on requested size
    [1] https://msdn.microsoft.com/en-us/library/wb1s57t5(v=vs.80).aspx
    [2] https://msdn.microsoft.com/en-us/library/5471dc8s(VS.80).aspx

An example of a DIY malloca...
  * might have the advantage of tuning MAX_ALLOCA_CUTOFF post-compilation
  * minGW gcc might not have malloca
  * if large allocations go on the heap, maybe MAX_LONG_FILE_PATH test not
required, just MAX_ALLOCA_CUTOFF

so its more obviously symmetrical with FREE_WIDECHAR_PATH.

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150825/cfd25355/attachment-0001.htm

More information about the Vm-dev mailing list