Assuming touch etc. is not involved, just standard open, write, close, link system calls.

One process is updating files, another is periodically stating to see if they've changed and reloading the contents. If it possible for the second process to end up with an incorrect view of a file, if it reloaded before the first had completed the write?

Looking primarily at Linux ext4 file-systems, but information for others could be useful if they differ.


POSIX requires that read-after-write() always return the correct data, according to http://pubs.opengroup.org/onlinepubs/007908799/xsh/write.html :

After a write() to a regular file has successfully returned:

  • Any successful read() from each byte position in the file that was modified by that write will return the data specified by the write() for that position until such byte positions are again modified.

The file mtime is not updated until the end of the write in Linux, so it shouldn't be possible to see an updated mtime without seeing the data that caused that mtime update.

Upon successful completion, where nbyte is greater than 0, write() will mark for update the st_ctime and st_mtime fields of the file

Ext4 tries to ensure POSIX-compliance, so you should be safe in this case, but not every filesystem is fully POSIX compliant, so YMMV.

  • That specification (and for fsync) don't say anything about when the mtime is actually updated and visible to other processes. The key appears to be "as defined for synchronised I/O file integrity completion", but I don't see where that's actually defined. – OrangeDog Apr 19 '18 at 8:54

Depends on what granularity you want. Single write() calls should be atomic (*). But if the application does multiple write calls as part of a single logical operation, the other process might wake up in the middle to read only part of it.

*) The system call can return after writing only a part of the data, this will be indicated in the return value. But I don't know if that can happen on local files on Linux.

Consider this sequence:

--task 1--                  --task 2--
write()                     ..  
..                          stat()
..                          read()

If the two writes on the left are part of a single logical modification, task 2 just read only a part of that modification.

  • But in that case does every write (or flush) update the mtime, therefore the second will get it on the next check? – OrangeDog Mar 10 '17 at 13:02
  • It should, but I'm not sure how accurate the timestamps are in practice. It may depend on the programming language / environment too: e.g. Perl's default stat only gives a granularity of a full second. – ilkkachu Mar 10 '17 at 16:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.