An analysis of the situation so people out of context can understand better the forces in play here :) - *Working directory and files constant property:* files defined using a *relative path* are created relative to the working directory. In other words: File named: 'something/other/myfile.txt' will be created in FileSystem workingDirectory. This was always like this when we used the file primitives. The diverging behaviour was introduced actually by FileSystem: FileSystem used to create by default all files relative to the image directory. And at some point all tools adapted to that and the correct behaviour was hidden. - *Change in working directory:* Before, pharo always satisfied the following property: FileSystem workingDirectory = FileSystem imageDirectory This is no longer true for every case. Now, the workingDirectory is aligned with the process' working directory (This is the equivalent to getcwd() in C, pwd command in linux, $PWD in bash). I explained a couple of weeks ago in an email, this may break some eggs, specially for those tools that wrongly assume FileSystem workingDirectory = FileSystem imageDirectory. Tools requiring imageDirectory should use imageDirectory explicit. At least that will keep backwards compatibility. For other cases, we should probably study them case by case and provide a satisfying solution. This change does however not affect everybody, and most of the times it is backwards compatible: ** This does not affect in general people launching usually pharo from the command line and using zeroconf: $ wget get.pharo.org/... $ ./pharo Pharo.image ## Here, FileSystem workingDirectory *=* FileSystem imageDirectory because I launched my image from the directory where my image is! ** This does affect people that are: - launching Pharo doing double click. In this case, we saw with Denis and Pavel a week ago that osx assigns as working directory the root directory "/" Users of files should be aware of this and applications should not abuse the workingDirectory. If they want to enforce the imageDirectory, they should do so explicitly. - launching Pharo from the pharo launcher (taken from this thread) Apparently the pharo launcher is launching the image from a directory internal to the launcher. This means that the working directory will be assigned to that directory. I'd expect that the directory structure is private to the launcher... I find even strange that the launcher puts pharo-local where the image is... Given this, possible solutions are: - On fileout, chose a correct directory when launched from double click - Make the pharo launcher set a well-known working directory when launching an image - one possibility is to set $HOME - another possibility is to set the image directory (this will keep backwards compatibility) @Stef: about the #fullname. It is not there because it is not implemented :). We did not have the possibility of calculating a correct full path until a couple of weeks ago (and before, even if we did so, it couldn't be done without introducing a dependency to a non-kernel package). On Thu, Nov 9, 2017 at 9:43 AM, Christophe Demarey < christophe.demarey@inria.fr> wrote:

Hi Stefan,

...

Le 8 nov. 2017 à 15:56, stephan <stephan@stack.nl> a écrit :

I run into all kinds of issues with the directory structure used by the new PharoLauncher. pharo-local seems to be shared now for multiple images.

I never saw this issue. PharoLauncher does not have influence on the pharo-local directory of launched images. pharo-local directory is located in the same directory as the image run.

in a Pharo 6.1 image: localDirectory ^ self class userLocalDirectory ifNil: [ (self imageDirectory / self class defaultLocalDirectoryName) ensureCreateDirectory ]

userLocalDirectory ^ UserLocalDirectory ifNil: [ FileLocator workingDirectory / self defaultLocalDirectoryName ]

Maybe you run Pharo 7 images and this change « Build #203: 05723-Default-Working-Directory » has a side effect?

...

That makes using configurations practically impossible as they are not expecting to have to deal with pre-downloaded older and newer monticello files. The missing sources files is less of a problem.

Stephan

-- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Le 9 nov. 2017 à 10:18, Guillermo Polito <guillermopolito@gmail.com> a écrit :

- launching Pharo from the pharo launcher (taken from this thread) Apparently the pharo launcher is launching the image from a directory internal to the launcher.

In the Pharo launcher, I explicitly set the current working directory to the VM directory so that the VM can find its files.

This means that the working directory will be assigned to that directory. I'd expect that the directory structure is private to the launcher... I find even strange that the launcher puts pharo-local where the image is…

Pharo Launcher does not choose where to put pharo-local. It just stands in the standard place aside the launched image.

Given this, possible solutions are: - On fileout, chose a correct directory when launched from double click - Make the pharo launcher set a well-known working directory when launching an image - one possibility is to set $HOME - another possibility is to set the image directory (this will keep backwards compatibility)

I think the last solution: set the working directory to the image directory is the best option. It will require to find another way to get the vm find its files (probably with LD_LIBRARY_PATH, do not know if it will be enough) and a lot of testing. I will try to work on it next week. Stephan, could you open an issue for that on GH?

thanks

Le 9 nov. 2017 à 20:10, stephan <stephan@stack.nl> a écrit :

On 09-11-17 11:49, Christophe Demarey wrote:

...

Stephan, could you open an issue for that on GH?

https://github.com/pharo-project/pharo-launcher/issues/51

Stephan

On 9 November 2017 at 10:18, Guillermo Polito <guillermopolito@gmail.com> wrote:

An analysis of the situation so people out of context can understand better the forces in play here :)

- Working directory and files constant property: files defined using a *relative path* are created relative to the working directory. In other words: File named: 'something/other/myfile.txt' will be created in FileSystem workingDirectory. This was always like this when we used the file primitives. The diverging behaviour was introduced actually by FileSystem: FileSystem used to create by default all files relative to the image directory. And at some point all tools adapted to that and the correct behaviour was hidden.

- Change in working directory: Before, pharo always satisfied the following property: FileSystem workingDirectory = FileSystem imageDirectory

I realise I'm being pedantic, so apologies in advance and I certainly don't mean to offend anyone. Just for completeness: This constraint was actually introduced in Pharo 6 around March 2017. I think it was issue #19717 (https://pharo.fogbugz.com/f/cases/19717/FileSystem-workingDirectory-wrong-af...). Before that the workingDirectory was held in an instance variable and could be changed (although it looks like no one actually did that). #20164 (https://pharo.fogbugz.com/f/cases/20164/Caching-DiskStore-defaultWorkingDire...) put the workingDirectory back in to a class variable since the performance gain is significant (one application saved 12 seconds from the change).

This is no longer true for every case. Now, the workingDirectory is aligned with the process' working directory (This is the equivalent to getcwd() in C, pwd command in linux, $PWD in bash).

Cheers, Alistair

I explained a couple of weeks ago in an email, this may break some eggs, specially for those tools that wrongly assume FileSystem workingDirectory = FileSystem imageDirectory. Tools requiring imageDirectory should use imageDirectory explicit. At least that will keep backwards compatibility. For other cases, we should probably study them case by case and provide a satisfying solution.

This change does however not affect everybody, and most of the times it is backwards compatible:

** This does not affect in general people launching usually pharo from the command line and using zeroconf: $ wget get.pharo.org/... $ ./pharo Pharo.image ## Here, FileSystem workingDirectory = FileSystem imageDirectory because I launched my image from the directory where my image is!

** This does affect people that are: - launching Pharo doing double click. In this case, we saw with Denis and Pavel a week ago that osx assigns as working directory the root directory "/" Users of files should be aware of this and applications should not abuse the workingDirectory. If they want to enforce the imageDirectory, they should do so explicitly.

- launching Pharo from the pharo launcher (taken from this thread) Apparently the pharo launcher is launching the image from a directory internal to the launcher. This means that the working directory will be assigned to that directory. I'd expect that the directory structure is private to the launcher... I find even strange that the launcher puts pharo-local where the image is...

Given this, possible solutions are: - On fileout, chose a correct directory when launched from double click - Make the pharo launcher set a well-known working directory when launching an image - one possibility is to set $HOME - another possibility is to set the image directory (this will keep backwards compatibility)

@Stef: about the #fullname. It is not there because it is not implemented :). We did not have the possibility of calculating a correct full path until a couple of weeks ago (and before, even if we did so, it couldn't be done without introducing a dependency to a non-kernel package).

On Thu, Nov 9, 2017 at 9:43 AM, Christophe Demarey <christophe.demarey@inria.fr> wrote:

...

Hi Stefan,

...

Le 8 nov. 2017 à 15:56, stephan <stephan@stack.nl> a écrit :

I run into all kinds of issues with the directory structure used by the new PharoLauncher. pharo-local seems to be shared now for multiple images.

I never saw this issue. PharoLauncher does not have influence on the pharo-local directory of launched images. pharo-local directory is located in the same directory as the image run.

in a Pharo 6.1 image: localDirectory ^ self class userLocalDirectory ifNil: [ (self imageDirectory / self class defaultLocalDirectoryName) ensureCreateDirectory ]

userLocalDirectory ^ UserLocalDirectory ifNil: [ FileLocator workingDirectory / self defaultLocalDirectoryName ]

Maybe you run Pharo 7 images and this change « Build #203: 05723-Default-Working-Directory » has a side effect?

...

That makes using configurations practically impossible as they are not expecting to have to deal with pre-downloaded older and newer monticello files. The missing sources files is less of a problem.

Stephan

--

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13