Thank you for the feedback, Dave! Given you reviewed the change set and did not identify any regressions, I just have merged it via Files-ct.189/System-ct.1297. :-)<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font><br>
<br>
On 2022-01-31T12:38:01-05:00, lewis@mail.msen.com wrote:<br>
<br>
> Hi Christoph,<br>
> <br>
> Your changes in DoItFirstAfterStartup.1.cs look correct to me. I<br>
> tested on Linux and the --cwd command line option still works as<br>
> expected. So +1 for putting this in trunk. As an aside, I notice<br>
> that the existing FileDirectory class>>startUp method is mis-categorized,<br>
> we should move it to "system start up".<br>
> <br>
> I am happy to do the merge if you like, but I'm not sure if I can do it today.<br>
> <br>
> On Sun, Jan 30, 2022 at 09:02:22PM +0100, christoph.thiede at student.hpi.uni-potsdam.de wrote:<br>
> > Hi Marcel, Hi Dave,<br>
> > <br>
> > I don't see why you would expect this to work. The normal SourceFiles array already contains a writable pointer to the changes file, so of course it cannot be opened writable again. There can only be one writable pointer to a file at one time, at least on Windows. I am more surprised that this rule does not apply on Linux/macOS.<br>
> > <br>
> <br>
> The restriction on opening multiple writeable pointers to a file<br>
> is a Windows design constraint that does not exist on other<br>
> platforms. Like many such things, it is either a bug or a feature<br>
> depending on your point of view ;-)<br>
> <br>
> <br>
> > On Windows, apparently we need to close the changes file before re-opening it. We can either implement this manually or apply my proposed patch instead, because even conceptually, I don't see a real sense in making #openSourceFiles itself idempotent. :-)<br>
> > <br>
> <br>
> Your changes handle this is a good way. So yes, calling #closeSourcesFiles<br>
> first would probably take care of the issue on Windows, but I prefer<br>
> your solution.<br>
> <br>
> > Dave, you were probably unable to reproduce this in a debugger because once you have replaced the SourceFiles with a read-only pointer and old pointer has been GC'ed, the issue does not occur any longer. There is no limit for parallel read-only pointers on a file.<br>
> > <br>
> > Best,<br>
> > Christoph<br>
> > <br>
> <br>
> Ah, good. It makes perfect sense now :-)<br>
> <br>
> Dave<br>
> <br>