Here’s the scenario:
-
A central machine running Linux is a “data store” for a number of instruments.
-
The instruments each have a PC, and each one has a remote mount (SMB) on the data store to which it write data files captured by the instrument.
-
The instrument PCs run a wide range of operating system including some really old ones.
-
The instrument PCs hardware clocks are not synchronized, and synchronizing would be problematic for a number of reasons.
-
Various other fixes (e.g. not using SMB, upgrading instrument operating systems, developing stuff to run on the instruments) are likewise problematic.
What we want to write is a “grabber” application that notices when an instrument writes a file to the data store via its remote mount, and then quickly copies the file somewhere else. The current plan is to use the Linux inotify subsystem to watch for file system events on the directories / trees that the files are likely to arrive in, and then do the copying.
My concern is that the fact the fact that we don’t have synchronized clocks is going to be a problem. Is this concern justified?
The concern is not justified.
Linux inotify is an user space API that exposes the Linux fsnotify sub-system. This kernel file system is wired into the general file system layer of the kernel (called VFS). It gets the notification of a creation of a new file directly from the file system code by a callback function, and not by comparing the creation or access dates of the files in a directory. As such, it will not be influenced at all by the time stamps on the files, so the clocks on the different client machine would not matter at all.
To be sure you audit the code for the inotify_should_send_event() send event function, that checks whether an event needs to sent for a tracked file or directory (see here: http://lxr.linux.no/linux+v3.0.4/fs/notify/inotify/inotify_fsnotify.c#L144). Note there is no reference whatsoever to time. In the same spirit the main fsnotify function (http://lxr.linux.no/linux+v3.0.4/fs/notify/fsnotify.c#L296) in the kernel does not reference time stamps anywhere, so clocks will not affect this interface at all.
I hope this helps.