gd_desync(3)

NAME
gd_desync — check for a change of metadata on disk

SYNOPSIS
#include <getdata.h>

int gd_desync(DIRFILE *dirfile, unsigned int flags);

DESCRIPTION
The function determines whether the metadata of the loaded has become desynchronised from the format specification fragments on disk, due to a third party modifying the Dirfile metadata on disk after GetData opened it. If has become desynchronised, this function can, optionally, reload the dirfile. The argument influences how the function works. It should be zero or more of the following flags, bitwise or'd together: Ignore GetData's internal directory cache, and use the format fragments' full path when checking for modifications. This flag is of particular importance when the passed to or directory paths used in included fragments, contain symbolic links: with this flag, these symbolic links will be re-evaluated. Without it, the target of the symbolic links in effect when the dirfile was first opened will be considered instead. If this flag is specified, and detects desynchronisation, the Dirfile will be re-opened in place using the exiting pointer. In this case, upon a positive result from this function, the caller must discard all cached information about the dirfile, even the assumption that has been successfully opened. Re-opening the dirfile is equivalent to calling and then with the same arguments used when originally creating except that the pointer doesn't change its value. As a result, this function may invoke the registered parser callback function (see and

RETURN VALUE
When successful, this function returns zero if the loaded dirfile has not desynchronised, or one if it has. On error, a negative-valued error code is returned, regardless of desynchronisation. Possible error codes are: The library was unable to allocate memory. The supplied dirfile was invalid. An error occurred while trying to obtain the modification time of a fragment.

Additionally, if GD_DESYNC_REOPEN is used, this function may fail for any of the reasons listed in the and manual pages.

The error code is also stored in the DIRFILE object and may be retrieved after this function returns by calling A descriptive error string for the error may be obtained by calling

LIMITATIONS
The current implementation uses file modification times as reported by stat(2) to detect changes. These times have a granularity of, at best, one second. As a result, desynchronisation will not be detected in the case when a fragment is modified, then GetData reads it, then the fragment is modified again, all within one second. The caller may wish to perform its own monitoring using the pathnames returned by

On systems lacking a POSIX.1-2008 conformant fstatat(2) (q.v.), this function may always operate as if GD_DESYNC_PATHCHECK had been specified, regardless of the actual

HISTORY
The function appeared in GetData-0.8.0. In GetData-0.10.0, the error return from this function changed from -1 to a negative-valued error code.

SEE ALSO
fstatat(2), stat(2),