On Tue, Jun 28, 2016 at 6:04 PM, Max Leske <maxleske at gmail.com> wrote:
> Hi,
>
> Opening the same image twice works fine as long as no writes to the .changes file occur. When both images write to the .changes file however it will be broken for both because the offsets for the changes are wrong. This can lead to lost data and predominantly to invalid method source code, which is a pain with Monticello.
>
> I suggest that we implement a kind of lock mechanism to ensure that only one image (the first one opened) can write to the .changes file.
>
>
> I’ve opened an issue for Pharo here: https://pharo.fogbugz.com/f/cases/18635/The-changes-file-should-be-bound-to-a-single-image
>
>
> Cheers,
> Max

I just learnt something quite surprising that is probably important to
be aware of... "Locks given by fcntl are not associated with the
file-descriptor or open-file table entries. Instead, they are bound to
the process itself. For example, a process has multiple open file
descriptors for a particular file and gets a read/write lock using any
one of these descriptors. Now closing any of these file descriptors
will release the lock, the process holds on the file. The descriptor
that was used to acquire the lock in the first place might still be
open, but the process will loose its lock.  So, it does not require an
explicit unlock or a close ONLY on the descriptor that was used to
acquire the lock in fcntl call. Doing unlock or close on any of the
open file descriptors will release the lock owned by the process on
the particular file."

https://loonytek.com/2015/01/15/advisory-file-locking-differences-between-posix-and-bsd-locks/

cheers -ben