Oh, no. Long path prefix can not work for relative paths! Since my latest additions for long path support for the windows vm, you can not open an image file if the supplied path is not an absolute path. If you start Pharo with "Pharo.exe Pharo.image" an open-file-dialog shows up and you have to choose the image in this dialog. (If you have only one image file in the current directory, this image *is* found, this is because the windows vm searches the current directory for a single .image file) Sorry for that, I'll fix it. nicolai 2015-09-04 22:19 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:

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=sharin...

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