That sounds like a great idea.
On configurations where overwrite-by-rename is a problem, perhaps an alternate of "copy the existing image to a *.bak file" would work?
Perhaps the image save primitive could respond to a VM command-line switch (or in-image VM parameter?) selecting among three behaviours:
1. The current overwrite-in-place, risk-of-corruption behaviour 2. Overwrite-by-rename if possible 3. Make backup copy before overwrite-in-place
Regards, Tony
On 1/29/20 6:00 PM, Thiede, Christoph wrote:
Hi all,
some months ago, I corrupted my image by accidentally shutting down the host system while saving the image file (many of my images are > 500 MB, so this can take a few seconds even on an SSD). The same can happen due to various other IO/connection issues, so here's an idea: Couldn't we always use overwrite-by-rename when saving the image file? I. e., first the image into a new temporary file and, after saving has completed, replace the original file with that temp file (via mv)? This would ensure the image file's integrity.
A possible disadvantage, though, would be that some filesystems, such as NTFS, associate meta-information with the file identity, which changes when using the overwrite-by-rename approach. Also, technologies such as FileSystemWatcher would be confused for the same reason. However, afaik overwrite-by-rename is a quite common approach, in primary for big and sensitive files.
However, what are your opinions about this topic? :-)
Best,
Christoph