Feature Request: Add support for locking changes file to prevent multiple instances sharing it

[jraiford1]

It is currently easy to open the same image multiple times and have them fight over the changes file. It would be better if the changes file were locked so subsequent attempts to use it would fail.

[timrowledge]

This also relates to an ancient bug report of mine - the file primitives are very unfortunately based on the wrong-headed approach of assuming that a "move write pointer to X" followed by some code, followed by "write Y bytes to current file pointer location". This provably causes corruption of files in some cases.
The safer approach would be a primitive that does "write Y bytes to file F at location X" atomically.

Another related issue is that modern OSs love to buffer the buffered buffers of buffering bytes and only write to actual files (which might be buffered!) on alternate Thursdays when there is an X in the month.

To make opening an image multiple times safe(r-ish) one might consider having the root image be read-only and any save handle the error and insist on a new location. A similar handler of attempting to write to the changelog could copy the file first. This would seriously improve the utility of the packages, and especially the all-in-one, by keeping the original image clean and available as a 'recovery partition'.