Created attachment 10673 [details] Reproducer This was originally reported agains emacs: Emacs complained that the file has changed on disk while it really has not: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19607 However, the reproducer (attached) showed that the problem seems to be in the cifs client. What it does is write fsync fstat close stat The problem is that the second stat returns a slightly different timestamp. Example output: $ ~/fsync-mtime stat #1: 1422393669.293420542 stat #2: 1422393669.293420500 This causes the editor to detect a change.
$ uname -r 3.19.0-0.rc6.git0.1.vanilla.mainline.knurd.1.fc20.x86_64
cifs vfs should probably act a filesystem with 100ns resolution, that would be the fix for this problem. Can the cifs developers comment and look into this, please? Is full ns resolution something that the SMB POSIX extensions try to address? In that case cifs should of course act accordingly different.