Thanks a lot andreas!!!!!!
On Thu, Sep 7, 2017 at 1:53 AM, Andreas Sunardi <a.suna...@gmail.com> 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
>
> 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 <akgrant0...@gmail.com>
> 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
>> > <stepharo.s...@gmail.com>
>> > 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
>> > <a.suna...@gmail.com>
>> > 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
>> >
>> >
>> >
>>
>
