Some interesting thoughts below - but my understanding is these images are being created by Pharo Launcher , so they should be isolated from one another? I also donât understand why you can load with 32bit (multiple images) but only once with 64bit. Do we load radically different git code with longer paths on 64bit? (Strange isnât it?) Possibly worth caveating this is with 2-3 users so far, and only noticed this pattern with the last one. Also - has anyone created an issue for these path problems - Iâm curious if my results match anything else. Tim Sent from my iPhone
On 21 Feb 2019, at 16:01, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
Tim Mackinnon wrote
Hi Ben - while I understand the description below - why would it work the first time (no errors) and then fail the second time in a fresh image? Are we really sure its just down to non-determinism of the load process (possibly - but it seems very suspicious to me). There is something more fishy about windows going on I suspectâ¦
The Iceberg cache path is relative to the image folder, so it's at least possible to have success in one image, located in C:\Pharo\testImage\, while another image, reciding in something like C:\Users\sam\Documents\Pharo\images\exercism-test-run-7.0-32\ , fails to load the exact same filetree package...
Tim Mackinnon wrote
I will track down the Exercism dependencies to see if any of them are FileTree - having said that, on OSX (where it loads cleanly - I would expect to be able to find one of those methods in my image - but again I canât? They look like valid methods - but why arenât they in my image? Its like the load process is downloading other stuff on its own and then not loading that into the image?
Yeaaah, that sounds fishy. But at least the first method sounds like a test, which may be part of the packages in the git repo that gets cloned without being loaded by Metacello, if the Metacello dependency specifies a *Core group which does not include tests.
Tim Mackinnon wrote
Iâm just worried that we keep blaming windows (and yes its dumb having a file length restriction I this day and age) - but maybe we are missing another problem too?
Tim
To be pendantic, (and not of much actual help, sorry :/ ) the problem isn't really with Windows, which provides API's for getting file info that handle long paths just fine, but with libgit, which is probably compiled against some POSIX stat implementation provided by Cygwin/mingw, which does not.
Cheers, Henry
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html