[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 10:12:48 EST 2019


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…

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?

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

> On 21 Feb 2019, at 13:20, Ben Coman <btc at openinworld.com> wrote:
> 
> 
> 
> On Thu, 21 Feb 2019 at 20:36, Tim Mackinnon <tim at testit.works <mailto:tim at testit.works>> wrote:
> 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 
> 
> These files are both method names which indicates FileTree format rather than Tonel (and these "failed to stat file" errors on Windows is one of the reasons for the move to Tonel).  It may be from one of the dependencies that are pulled in. To identify which, search for that file under `pharo-local/iceberg` directory.  I believe the repo may have been cloned successfully, its just the libgit binary can't `stat` long filenames.  If that turns out the be untrue, use commandline git to complete the clone and you will likely see it.
>  
> 
> 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
> 
> as above.
> 
>  
> (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?
> 
> Filetree on Windows is constrained by long filename issues with libgit.
> 
> cheers -ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20190221/29c95029/attachment.html>


More information about the Pharo-users mailing list