[Pharo-dev] [squeak-dev] The .changes file should be bound to a single image

Max Leske maxleske at gmail.com
Thu Jun 30 07:59:37 UTC 2016

> On 30 Jun 2016, at 05:09, Ben Coman <btc at openInWorld.com> wrote:
> 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

Which would solve the problem of a crashed image not cleaning up its lock. Thanks for sharing Ben.

More information about the Squeak-dev mailing list