Thanks guille for this analysis. I would move it to Pharo 8.0 Now I think that we should revive your analysis on state because I would love to have first class objects with a good and nice logic for such cases and others. The lifetime of a variable looks more complex than it looks.
> On 8 Jan 2019, at 12:19, Guillermo Polito <guillermopol...@gmail.com> wrote: > > Hi all, > > I was checking issue https://pharo.fogbugz.com/f/cases/19852 > <https://pharo.fogbugz.com/f/cases/19852> which is about the problems that > arise when we move an image of location, and moreover when we move it between > different platforms (windows to linux or mac for example). > > The problem are dangling file references pointing to invalid locations. > > We have found 4 of them: > > SystemResolver localdirectory is cached in a class variable > GTPlaybook caches the cache and stash directories in class variables > OMSessionStore retrieves at some point during startup an invalid file > reference from the (wrongly cached) local directory > IceLibgitRepository Sharedrepositorieslocation is also cached > > All these are actually caused by settings, whose behavior is not defined when > an image is moved. > There are several strange issues like, if we store settings, the local > directory is stored, and then all images will (wrongly) use the same > pharo-local directory of the first image. This is particularly annoying when > using the launcher for example :). > > Now, we can leave this as it is right now and just move it to pharo8. > A quick fix for Pharo7 would be removing those settings and avoiding caching, > but that is probably very disruptive too... > > Opinions? > > Guille
