Understanding read syscall

I’m reading man read manual page and discovered that it was possible to read less then the desired number of bytes passed in as a parameter:

It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a termi‐nal), or because read() was interrupted by a signal.

I have the following situation:

1. Some process moved a file into a directory I’m listening to IN_MOVED_TO inotify events.
2. I receive a IN_MOVED_TO event, open a file and start reading it till the EOF is reached
3. No other processes modify the moved at 1. file (After it is moved it is left unchanged all the time)

Is it guaranteed that if read returns the number of bytes read less then I requested then the next call to read will return 0? I mean the situation like ‘reading 1 000 000 000 by a single bytes for a gigabyte file’ is forbidden by the documentation

Answer

Is it guaranteed that if read returns the number of bytes read less then I requested then the next call to read will return 0?

No, not in practice. It should be true if the file system is entirely POSIX compliant, but many of them are not (in corner cases). In particular NFS (see nfs(5)) and FUSE or proc (see proc(5)) are not exactly POSIX compliant.

So in practice I strongly recommend handling the “read returns a smaller number of bytes than wanted case”, even if you are right to believe that it should not happen. Handling that “impossible” case should be easy for you.

Notice also that inotify(7) facilities don’t work with bizarre filesystems like NFS, proc, FUSE, … Think also of corner cases like, inside an Ext4 file system, a symlink to an NFS file,; or bind mounts, etc…