2017.05.22 19:34 "[Tiff] Support for fsync", by Roger Leigh

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/