Thank you all for your feedback.

@ben,

- yes malloca is not supported by mingw ( or I did not get it to work)

- and we don't have to consider recursive calls

I think we are save by using alloca. I did some tests with awfully long path names.

I made some more little changes for retrieving the file permissions. Don't use the stat() function, because

this did not work for long path names ( and it doesn't worked well for paths with non ascii characters).

I created a pull request for the pharo-vm git project.

nicolai

2015-08-25 8:35 GMT+02:00 Hern��n Morales Durand <hernan.morales@gmail.com>:

2015-08-24 4:31 GMT-03:00 Nicolai Hess <nicolaihess@web.de>:

Hi Hern��n

Thanks for your feedback

2015-08-24 8:13 GMT+02:00 Hern��n Morales Durand <hernan.morales@gmail.com>:

Nicolai

2015-08-23 8:44 GMT-03:00 Nicolai Hess <nicolaihess@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.

Using Win 8.1, I confirm FileList tree now is reading directories beyond 260 limit, without need to #initialize DiskStore.

However there should be another concern with GitFileTree uncompression because loading Aconcagua/Chalten, etc with your new VM in a directory name with more characters, still signals File not found :(

I tried Aconcagua from Catalogbrowser in pharo 5.0 and it worked for me.

Can you show what path is the base path, the working directory of your pharo package-cache/github directory. Is there something special in your path name or the disk?

Nicolai, the path is the one which I reported here http://forum.world.st/Loading-Chalten-amp-Aconcagua-error-td4844694.html

I have nothing special in the path name, not special characters or so.

I tried today again with your VM, same path, same image, but before loading the configuration I removed the whole github-cache/* contents, and it worked.... so I am confused. So I checked with old VM again and yep the FileDoesNotExists came back. Conclusion: Your VM actually fixes the issue, but cleaning github-cache did something, there could be another bug there...

��

��

Is the VM using the "Unicode-aware API"? According to this guys http://serverfault.com/questions/163419/window-256-characters-path-name-limitation such Win Unicode API would let VM to use the 32767 bricks

I am not sure, we are using all file/directory operations that should use the unicode version with multibyte char (CreateFileW / FindFirstFileW / ...)

��

Ok, thanks for checking.

��

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.

Thank you Nicolai for your effort, I know it's hard to dive into depths with C.

��

Hern��n

nicolai