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
> 
> 
>