2017.05.22 22:44 "Re: [Tiff] Support for fsync", by Bob Friesenhahn
Would it be worth considering the addition of a new function e.g. TIFFSync[Data] which would simply call fsync(2) or its Windows equivalent on the open file? It could potentially also call TIFFlush internally to be sure it's committing a consistent state. This would mean I can issue TIFFSync() prior to TIFFClose, or TIFFSyncData as I write out each IFD, and be sure the the data writes completed when the call returns (or failed).
GraphicsMagick provides an option (MAGICK_IO_FSYNC=TRUE environment variable) to fsync after a file is written. I don't know if anyone uses it.
I think that your proposal worth considering and implementing. All that is needed is a source patch, with associated documentation.
Unless the parent directory is also synchronized, there is a possibility of losing a whole new file, even if fsync has been called on the file. For example:
#include <sys/types.h>
#include <dirent.h>
// Synchronize a specified directory path to underlying store int sync_directory(const char *dirpath)
{
int status = 0;
DIR * dir = opendir(dirpath);
if ( dir != NULL )
{
int dfd = dirfd(dir);
if ( dfd >= 0 )
{
// Synchronize directory entry of the given file
status = fsync(dfd);
}
else
{
status = -1;
}
closedir(dir);
}
else
{
status = -1;
}
return status;
}
Note that there is also fdopendir() which opens the directory of a open file descriptor fd, which libtiff may already have. This may be easier than using opendir().
Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/