> On 30 Jun 2016, at 05:09, Ben Coman <b...@openinworld.com> wrote: > > On Tue, Jun 28, 2016 at 6:04 PM, Max Leske <maxle...@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.
