Hi Stef,

��t 9. 7. 2019 v��21:30 odes��latel ducasse <stepharo@netcourrier.com> napsal:
Pavel��

I looked at your PR and I have some questions:
- could the fileReference have a class/instance var pointing to the store instead of having yet another
global access to a singleton like class :)

��FileReference has inst. var pointing to a FileSystem that points to a Store. There is no global access from this perspective.
Of course, I tried to avoid making new globals as much as possible. The only exception if usage in File class because
it has very low level API that does not work with file references


- I was wondering why you have macStore and unixStore and �����
I imagine to capture the difference but then why there is duplicated code
e.g.��file: path uid: uidInteger gid: gidInteger looks the same

The ideal solution here would be the Trait usage for read-only API but in Kernel it is not possible to use it. The current implementation
uses different strategies for every platform. For every one of them, I added a subclass for read-only strategy. They have the same
content (which is unfortunate implementation detail) but the strategy design here is definitely the way to go.
��

I hope that the��class comment explains it :)

:-) I will improve it
��

- Why do you have a class var for each store? and not one single metaclass inst var in the superclass?

There are no class variables of Store classes. What do you mean, exactly?

-- Pavel
��

Stef��


On 9 Jul 2019, at 14:28, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:

Hi,

the current Pharo cannot deal very well in situations when you want to run multiple instances from one image file, especially on Windows, which complicates the setup of parallel applications.�� It is not able to work reasonably on read-only file-systems too. That's why I did the next attempt to improve this functionality of the system.

In summary:
- the image can be executed with --readOnlyMode image argument
- the basic system tries to survive such limitation. The changes file is in read-only mode and new sources are installed into compiled methods directly, Ombu does not save content, Playground does not save cache etc.
- PharoDebug.log and placeholder files on Windows are not created
- the limitation is only on image-level so it is easy to bypass it.
- the presence of the old file streams makes everything uglier and messier

We have an open PR for this issue:��https://github.com/pharo-project/pharo/pull/3837

Comments and reviews are welcome.

-- Pavel