[Pharo-users] Windows 64bit, long filename issue but after a second load, how to categorise and report this?

Tim Mackinnon tim at testit.works
Thu Feb 21 07:35:33 EST 2019


We noticed a weird problem when testing the pharo exercism project.

When loading on Windows10 in a fresh 64bit image with the following evaluate in the playground:

Metacello new 
 baseline: 'Exercism'; 
 repository: 'github://exercism/pharo-smalltalk:master/dev/src';
 load.

The project seemed to load correctly (but we seemed to hit an issue with an http submit giving a 404 error - which weirdly works in 32bit and OSX 64/32). Anyway - the real question here is that when trying to reproduce this in a second fresh 64bit image 2 users now have reported getting the long filename error:

LGit_GIT_EEXISTS: Failed to stat file 'C:/Users/sam/Documents/Pharo/images/exercism-test-run-7.0-32...stance/testRaiseUnexpectedMessageWhenTooMuchMessages.st': The filename or extension is too long.

And the second user got the same but with a different filename: ruleRBUtlitiesMethodsRuleV1FalsePositve.st

I know there is a long standing problem with Windows and file path lengths - but why would it work the first time and then subsequently fail in fresh installs? Is something being cached on windows that isn’t on other platforms? (Writing this - I’m wondering if there is that shared pharo Iceberg setting for Share repos that might be implicated?)

Also - given Exercism is in Tonel format and those files aren’t in exercism, and in fact I’m struggling to find where they are defined (my images don’t have them) - there is something very weird going on.

I wonder if we have another error that is masking all of this?

Ultimately my question is - where is the Pharo issue that is tracking this problem? I’ve seen it mentioned lots of times here, but can’t see anything in the issues that I can tack the above onto?

For reference - our exercism issue is: https://github.com/exercism/pharo-smalltalk/issues/140

Tim


More information about the Pharo-users mailing list