From: Bob Friesenhahn <bfriesen@si...> - 2009-03-18 17:49:32
GraphicsMagick does its best to avoid data loss. Recently it came to
my attention that a file update pattern used prior to GraphicsMagick
1.2 may allow unexpected data loss (total loss of file data) on some
Linux filesystems. The problematic file update pattern is
rename tmp original
and was used by 'mogrify'. The problem is that some Linux filesystems
prioritize the rename more than the write and close operations and so
the file could be entirely lost, or corrupted after a system crash or
power failure (see
It is always possible to lose pending unflushed updates on crash or
power fail, but this Linux bug allows the rename to be recorded on
disk before the file data is even written yet.
Starting with GraphicsMagick 1.2, a different file update patten is
used which should not encounter this particular bug, but if the system
crashes, the original file may be saved under a different name. The
scheme that 1.2 and later uses is
rename original backup
It is still possible for data to be lost if 'remove backup' is given
elevated priority similar to 'rename' so that the backup is removed
before the file data has been written.
As an assurance of file integrity, in GraphicsMagick 1.3 or later a
fsync() may be enabled prior to every file close by setting the
environment variable MAGICK_IO_FSYNC to 'TRUE'. This assures that
file data is commited to disk before returning to the user.
Outside of 'mogrify' the problematic file update pattern is quite
commonly used by image processing scripts and so care should be taken
to not loose good images if the system crashes. Using
MAGICK_IO_FSYNC=TRUE is recommended if the file data is very important
and the system might crash or lose power.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/