[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...

http://stackoverflow.com/questions/5807612/on-the-use-and-abuse-of-alloca
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.

http://www.strchr.com/alloca
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

https://sourceware.org/ml/libc-alpha/2012-06/msg00246.html
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

----------
btw, perhaps rename CONVERT_MULTIBYTE_TO_WIDECHAR_PATH
to ALLOC_WIDECHAR_PATH_FROM_MULTIBYTE or similar
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