Pharo 6 FileSystem>>changeDirectory: is missing

> I found FileSystem class has changed from Pharo 5 to Pharo 6. I've been
> using FileSystem>>changeDirectory to make my program (Pharo 5) runs in the
> current working directory (thus able to find local files).
>
> This is now broken because #changeDirectory doesn't exist anymore. The
> change seems intentional.
>
> Question: Is there a different way in Pharo 6 do set working directory or is
> this a bug?
>
> --
> Andreas

> It isn't only #changeDirectory: method that is missing. Method #
> workingDirectoryPath: and instance variable workingDirectory are also missing.
>
> FileSystem >> changeDirectory: aPath
>   self workingDirectoryPath: (self resolve: aPath)
>
> FileSystem >> workingDirectoryPath: aPath
>   aPath isAbsolute
>     ifFalse: [ self error: 'Cannot set the working directory to a relative
> path' ].
>   workingDirectory := aPath
>
>
> To solve my problem, I implemented those and also fixed #initializeWithStore:
> and changed #workingDirectoryPath
>
> FileSystem >> initializeWithStore: aStore
>   store := aStore.
>   workingDirectory := store defaultWorkingDirectory
>
> FileSystem >> workingDirectoryPath
>   ^ workingDirectory
>
>
> Those are from Pharo 5. However, this breaks Monticello (when opening
> Monticello Browser). A FileSystem instance has instance variable
> workingDirectory set to nil. This should be impossible. I set 'self halt' in #
> initializeWithStore:. It doesn't get triggered, which tells me the instance
> isn't created by normal way. I don't know what's going on there.
>
>
> To fix it, I changed #workingDirectoryPath to
>
> FileSystem >> workingDirectoryPath
>   workingDirectory ifNil: [
>     workingDirectory := store defaultWorkingDirectory ].
>   ^ workingDirectory
>
>
> That solves my problem, but this is a specific tool. I don't know what other
> problems those changes will cause. This #ifNil: guard is not in Pharo 5, so
> that makes me worry. In general, the change in FileSystem gives impression that
> the it is intentional. But I haven't found the new Pharo 6.1 way to change
> working directory, if there's any.

> --
> Andreas
>
> On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse <[hidden email]>
> wrote:
>
>     Thanks for reporting.
>     I do not remember an action around me for this change.
>     Do you have the definition in Pharo 50 at hand?
>
>     Stef
>
>     On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi <[hidden email]>
>     wrote:
>     > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've been
>     > using FileSystem>>changeDirectory to make my program (Pharo 5) runs in
>     the
>     > current working directory (thus able to find local files).
>     >
>     > This is now broken because #changeDirectory doesn't exist anymore. The
>     > change seems intentional.
>     >
>     > Question: Is there a different way in Pharo 6 do set working directory or
>     is
>     > this a bug?
>     >
>     > --
>     > Andreas
>
>
>

> Hi Alistair,
>
> I found fogbugz #19717 where this was discussed.
>
> https://pharo.fogbugz.com/f/cases/19717/FileSystem-workingDirectory-wrong-after-image-moved-to-a-new-folder
>
> The issue seems to be the current working directory is saved in instance
> variable workingDirectory. When the image is moved to another directory,
> this workingDirectory becomes incorrect. Instance variable 'store', through
> its #defaultWorkingDirectory, always gives the right answer (however, this
> answer is the image directory, not directory where the command is invoked,
> which is the issue in #05723 you mentioned).
>
> Here's a snippet from fogbugz #19717 original problem on how to reproduce
> it:
> QUOTE
> 1/ open an image. evaluate './pharo-local' asFileReference and keep the
> inspector.
> 2/ save and quit
> 3/ move the image to another directory
> 4/ open the image
> 5/ evaluate self fullName on the file reference => it will give a wrong path
> with a reference to the working directory used at file reference creation.
> ENDQUOTE
>
> I don't know if it's still debatable, which './pharo-local' the file
> reference should refer to, but I think I agree with fogbugz #19717 that it
> should stay as relative path.
>
> But this is a separate issue than losing the ability to change working
> directory, which seems to me an unintentional side-effect in the solution.
> I'll see if I can jump onto $05723 to request support for changing working
> directory.
>
> On a side note, is current working directory the same as image directory in
> Pharo? I wonder why we have these issues if they are separate things. I
> haven't dived into this, so I can't say much.
>
> --
> Andreas
>
> On Wed, Sep 6, 2017 at 12:42 PM, Alistair Grant <[hidden email]>
> wrote:
>>
>> On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote:
>> > It isn't only #changeDirectory: method that is missing. Method #
>> > workingDirectoryPath: and instance variable workingDirectory are also
>> > missing.
>> >
>> > FileSystem >> changeDirectory: aPath
>> >   self workingDirectoryPath: (self resolve: aPath)
>> >
>> > FileSystem >> workingDirectoryPath: aPath
>> >   aPath isAbsolute
>> >     ifFalse: [ self error: 'Cannot set the working directory to a
>> > relative
>> > path' ].
>> >   workingDirectory := aPath
>> >
>> >
>> > To solve my problem, I implemented those and also fixed
>> > #initializeWithStore:
>> > and changed #workingDirectoryPath
>> >
>> > FileSystem >> initializeWithStore: aStore
>> >   store := aStore.
>> >   workingDirectory := store defaultWorkingDirectory
>> >
>> > FileSystem >> workingDirectoryPath
>> >   ^ workingDirectory
>> >
>> >
>> > Those are from Pharo 5. However, this breaks Monticello (when opening
>> > Monticello Browser). A FileSystem instance has instance variable
>> > workingDirectory set to nil. This should be impossible. I set 'self
>> > halt' in #
>> > initializeWithStore:. It doesn't get triggered, which tells me the
>> > instance
>> > isn't created by normal way. I don't know what's going on there.
>> >
>> >
>> > To fix it, I changed #workingDirectoryPath to
>> >
>> > FileSystem >> workingDirectoryPath
>> >   workingDirectory ifNil: [
>> >     workingDirectory := store defaultWorkingDirectory ].
>> >   ^ workingDirectory
>> >
>> >
>> > That solves my problem, but this is a specific tool. I don't know what
>> > other
>> > problems those changes will cause. This #ifNil: guard is not in Pharo 5,
>> > so
>> > that makes me worry. In general, the change in FileSystem gives
>> > impression that
>> > the it is intentional. But I haven't found the new Pharo 6.1 way to
>> > change
>> > working directory, if there's any.
>>
>> I couldn't find a fogbugz issue relating to this - if anyone knows the
>> issue, please post it here as it would be good to understand the
>> rationale for the change.
>>
>> My interpretation of the changes are that the decision was made to hard
>> code the working directory to the image directory.  There are quite a
>> few people who don't agree with this. :-)
>>
>> There is already a proposed patch to change the working directory to the
>> process working directory, see fogbugz #05723.
>> https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory
>>
>> The patch is waiting on a fix to include UFFI in the kernel.
>>
>> It currently doesn't allow the working directory to be changed,
>> but if I remember correctly, Rajula developed the code to change the
>> working directory.
>>
>> I think this approach has the advantage that it will automtically work
>> with forked processes, e.g. using OSProcess / OSSubprocess.
>>
>> It would be worthwhile adding a comment to the issue asking Rajula to
>> add the change directory functionality to the patch.
>>
>> Cheers,
>> Alistair
>>
>>
>>
>> > --
>> > Andreas
>> >
>> > On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse
>> > <[hidden email]>
>> > wrote:
>> >
>> >     Thanks for reporting.
>> >     I do not remember an action around me for this change.
>> >     Do you have the definition in Pharo 50 at hand?
>> >
>> >     Stef
>> >
>> >     On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi
>> > <[hidden email]>
>> >     wrote:
>> >     > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've
>> > been
>> >     > using FileSystem>>changeDirectory to make my program (Pharo 5)
>> > runs in
>> >     the
>> >     > current working directory (thus able to find local files).
>> >     >
>> >     > This is now broken because #changeDirectory doesn't exist anymore.
>> > The
>> >     > change seems intentional.
>> >     >
>> >     > Question: Is there a different way in Pharo 6 do set working
>> > directory or
>> >     is
>> >     > this a bug?
>> >     >
>> >     > --
>> >     > Andreas
>> >
>> >
>> >
>>
>

> Hi Alistair,
>
> I found fogbugz #19717 where this was discussed.
>
> https://pharo.fogbugz.com/f/cases/19717/
> FileSystem-workingDirectory-wrong-after-image-moved-to-a-new-folder
>
> The issue seems to be the current working directory is saved in instance
> variable workingDirectory. When the image is moved to another directory, this
> workingDirectory becomes incorrect. Instance variable 'store', through its #
> defaultWorkingDirectory, always gives the right answer (however, this answer is
> the image directory, not directory where the command is invoked, which is the
> issue in #05723 you mentioned).
>
> Here's a snippet from fogbugz #19717 original problem on how to reproduce it:
> QUOTE
> 1/ open an image. evaluate './pharo-local' asFileReference and keep the
> inspector.
> 2/ save and quit
> 3/ move the image to another directory
> 4/ open the image
> 5/ evaluate self fullName on the file reference => it will give a wrong path
> with a reference to the working directory used at file reference creation.
> ENDQUOTE

> I don't know if it's still debatable, which './pharo-local' the file reference
> should refer to, but I think I agree with fogbugz #19717 that it should stay as
> relative path.
>
> But this is a separate issue than losing the ability to change working
> directory, which seems to me an unintentional side-effect in the solution. I'll
> see if I can jump onto $05723 to request support for changing working
> directory.
>
> On a side note, is current working directory the same as image directory in
> Pharo? I wonder why we have these issues if they are separate things. I haven't
> dived into this, so I can't say much.

> --
> Andreas
>
> On Wed, Sep 6, 2017 at 12:42 PM, Alistair Grant <[hidden email]> wrote:
>
>     On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote:
>     > It isn't only #changeDirectory: method that is missing. Method #
>     > workingDirectoryPath: and instance variable workingDirectory are also
>     missing.
>     >
>     > FileSystem >> changeDirectory: aPath
>     >   self workingDirectoryPath: (self resolve: aPath)
>     >
>     > FileSystem >> workingDirectoryPath: aPath
>     >   aPath isAbsolute
>     >     ifFalse: [ self error: 'Cannot set the working directory to a
>     relative
>     > path' ].
>     >   workingDirectory := aPath
>     >
>     >
>     > To solve my problem, I implemented those and also fixed #
>     initializeWithStore:
>     > and changed #workingDirectoryPath
>     >
>     > FileSystem >> initializeWithStore: aStore
>     >   store := aStore.
>     >   workingDirectory := store defaultWorkingDirectory
>     >
>     > FileSystem >> workingDirectoryPath
>     >   ^ workingDirectory
>     >
>     >
>     > Those are from Pharo 5. However, this breaks Monticello (when opening
>     > Monticello Browser). A FileSystem instance has instance variable
>     > workingDirectory set to nil. This should be impossible. I set 'self halt'
>     in #
>     > initializeWithStore:. It doesn't get triggered, which tells me the
>     instance
>     > isn't created by normal way. I don't know what's going on there.
>     >
>     >
>     > To fix it, I changed #workingDirectoryPath to
>     >
>     > FileSystem >> workingDirectoryPath
>     >   workingDirectory ifNil: [
>     >     workingDirectory := store defaultWorkingDirectory ].
>     >   ^ workingDirectory
>     >
>     >
>     > That solves my problem, but this is a specific tool. I don't know what
>     other
>     > problems those changes will cause. This #ifNil: guard is not in Pharo 5,
>     so
>     > that makes me worry. In general, the change in FileSystem gives
>     impression that
>     > the it is intentional. But I haven't found the new Pharo 6.1 way to
>     change
>     > working directory, if there's any.
>
>     I couldn't find a fogbugz issue relating to this - if anyone knows the
>     issue, please post it here as it would be good to understand the
>     rationale for the change.
>
>     My interpretation of the changes are that the decision was made to hard
>     code the working directory to the image directory.  There are quite a
>     few people who don't agree with this. :-)
>
>     There is already a proposed patch to change the working directory to the
>     process working directory, see fogbugz #05723.
>     https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory
>
>     The patch is waiting on a fix to include UFFI in the kernel.
>
>     It currently doesn't allow the working directory to be changed,
>     but if I remember correctly, Rajula developed the code to change the
>     working directory.
>
>     I think this approach has the advantage that it will automtically work
>     with forked processes, e.g. using OSProcess / OSSubprocess.
>
>     It would be worthwhile adding a comment to the issue asking Rajula to
>     add the change directory functionality to the patch.
>
>     Cheers,
>     Alistair
>
>
>
>     > --
>     > Andreas
>     >
>     > On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse <
>     [hidden email]>
>     > wrote:
>     >
>     >     Thanks for reporting.
>     >     I do not remember an action around me for this change.
>     >     Do you have the definition in Pharo 50 at hand?
>     >
>     >     Stef
>     >
>     >     On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi <
>     [hidden email]>
>     >     wrote:
>     >     > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've
>     been
>     >     > using FileSystem>>changeDirectory to make my program (Pharo 5) runs
>     in
>     >     the
>     >     > current working directory (thus able to find local files).
>     >     >
>     >     > This is now broken because #changeDirectory doesn't exist anymore.
>     The
>     >     > change seems intentional.
>     >     >
>     >     > Question: Is there a different way in Pharo 6 do set working
>     directory or
>     >     is
>     >     > this a bug?
>     >     >
>     >     > --
>     >     > Andreas

> Hi Andreas,
>
> On Wed, Sep 06, 2017 at 04:53:27PM -0700, Andreas Sunardi wrote:
>> Hi Alistair,
>>
>> I found fogbugz #19717 where this was discussed.
>>
>> https://pharo.fogbugz.com/f/cases/19717/
>> FileSystem-workingDirectory-wrong-after-image-moved-to-a-new-folder
>>
>> The issue seems to be the current working directory is saved in instance
>> variable workingDirectory. When the image is moved to another directory, this
>> workingDirectory becomes incorrect. Instance variable 'store', through its #
>> defaultWorkingDirectory, always gives the right answer (however, this answer is
>> the image directory, not directory where the command is invoked, which is the
>> issue in #05723 you mentioned).
>>
>> Here's a snippet from fogbugz #19717 original problem on how to reproduce it:
>> QUOTE
>> 1/ open an image. evaluate './pharo-local' asFileReference and keep the
>> inspector.
>> 2/ save and quit
>> 3/ move the image to another directory
>> 4/ open the image
>> 5/ evaluate self fullName on the file reference => it will give a wrong path
>> with a reference to the working directory used at file reference creation.
>> ENDQUOTE
>
> Thanks for finding this!
>
> In #20164 I reintroduced caching the working directory, but update it
> when the session is stopped and started, so the above test produces the
> expected results.  As you can see in the comments for the associated PR,
> caching the value was a significant peformance improvement for at least
> one person.
> https://pharo.fogbugz.com/f/cases/20164/Caching-DiskStore-defaultWorkingDirectory
>
>
>> I don't know if it's still debatable, which './pharo-local' the file reference
>> should refer to, but I think I agree with fogbugz #19717 that it should stay as
>> relative path.
>>
>> But this is a separate issue than losing the ability to change working
>> directory, which seems to me an unintentional side-effect in the solution. I'll
>> see if I can jump onto $05723 to request support for changing working
>> directory.
>>
>> On a side note, is current working directory the same as image directory in
>> Pharo? I wonder why we have these issues if they are separate things. I haven't
>> dived into this, so I can't say much.
>
> Yes, which was the original driver for #05723.  After it is integrated
> the working directory will be the process working directory.  The image
> directory can of course still be accessed with FileLocator
> imageDirectory.
>
> Cheers,
> Alistair
>
>
>> --
>> Andreas
>>
>> On Wed, Sep 6, 2017 at 12:42 PM, Alistair Grant <[hidden email]> wrote:
>>
>>     On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote:
>>     > It isn't only #changeDirectory: method that is missing. Method #
>>     > workingDirectoryPath: and instance variable workingDirectory are also
>>     missing.
>>     >
>>     > FileSystem >> changeDirectory: aPath
>>     >   self workingDirectoryPath: (self resolve: aPath)
>>     >
>>     > FileSystem >> workingDirectoryPath: aPath
>>     >   aPath isAbsolute
>>     >     ifFalse: [ self error: 'Cannot set the working directory to a
>>     relative
>>     > path' ].
>>     >   workingDirectory := aPath
>>     >
>>     >
>>     > To solve my problem, I implemented those and also fixed #
>>     initializeWithStore:
>>     > and changed #workingDirectoryPath
>>     >
>>     > FileSystem >> initializeWithStore: aStore
>>     >   store := aStore.
>>     >   workingDirectory := store defaultWorkingDirectory
>>     >
>>     > FileSystem >> workingDirectoryPath
>>     >   ^ workingDirectory
>>     >
>>     >
>>     > Those are from Pharo 5. However, this breaks Monticello (when opening
>>     > Monticello Browser). A FileSystem instance has instance variable
>>     > workingDirectory set to nil. This should be impossible. I set 'self halt'
>>     in #
>>     > initializeWithStore:. It doesn't get triggered, which tells me the
>>     instance
>>     > isn't created by normal way. I don't know what's going on there.
>>     >
>>     >
>>     > To fix it, I changed #workingDirectoryPath to
>>     >
>>     > FileSystem >> workingDirectoryPath
>>     >   workingDirectory ifNil: [
>>     >     workingDirectory := store defaultWorkingDirectory ].
>>     >   ^ workingDirectory
>>     >
>>     >
>>     > That solves my problem, but this is a specific tool. I don't know what
>>     other
>>     > problems those changes will cause. This #ifNil: guard is not in Pharo 5,
>>     so
>>     > that makes me worry. In general, the change in FileSystem gives
>>     impression that
>>     > the it is intentional. But I haven't found the new Pharo 6.1 way to
>>     change
>>     > working directory, if there's any.
>>
>>     I couldn't find a fogbugz issue relating to this - if anyone knows the
>>     issue, please post it here as it would be good to understand the
>>     rationale for the change.
>>
>>     My interpretation of the changes are that the decision was made to hard
>>     code the working directory to the image directory.  There are quite a
>>     few people who don't agree with this. :-)
>>
>>     There is already a proposed patch to change the working directory to the
>>     process working directory, see fogbugz #05723.
>>     https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory
>>
>>     The patch is waiting on a fix to include UFFI in the kernel.
>>
>>     It currently doesn't allow the working directory to be changed,
>>     but if I remember correctly, Rajula developed the code to change the
>>     working directory.
>>
>>     I think this approach has the advantage that it will automtically work
>>     with forked processes, e.g. using OSProcess / OSSubprocess.
>>
>>     It would be worthwhile adding a comment to the issue asking Rajula to
>>     add the change directory functionality to the patch.
>>
>>     Cheers,
>>     Alistair
>>
>>
>>
>>     > --
>>     > Andreas
>>     >
>>     > On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse <
>>     [hidden email]>
>>     > wrote:
>>     >
>>     >     Thanks for reporting.
>>     >     I do not remember an action around me for this change.
>>     >     Do you have the definition in Pharo 50 at hand?
>>     >
>>     >     Stef
>>     >
>>     >     On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi <
>>     [hidden email]>
>>     >     wrote:
>>     >     > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've
>>     been
>>     >     > using FileSystem>>changeDirectory to make my program (Pharo 5) runs
>>     in
>>     >     the
>>     >     > current working directory (thus able to find local files).
>>     >     >
>>     >     > This is now broken because #changeDirectory doesn't exist anymore.
>>     The
>>     >     > change seems intentional.
>>     >     >
>>     >     > Question: Is there a different way in Pharo 6 do set working
>>     directory or
>>     >     is
>>     >     > this a bug?
>>     >     >
>>     >     > --
>>     >     > Andreas
>