Bug 11078 - unsupported timestamp resolution in cifs vfs:mtime changes after fsync(); fclose();
Summary: unsupported timestamp resolution in cifs vfs:mtime changes after fsync(); fcl...
Status: NEW
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 3.x
Hardware: x64 All
: P5 normal
Target Milestone: ---
Assignee: Steve French
QA Contact: cifs QA contact
Depends on:
Reported: 2015-01-27 21:26 UTC by Jakob Unterwurzacher
Modified: 2024-01-11 15:39 UTC (History)
3 users (show)

See Also:

Reproducer (1.41 KB, text/x-csrc)
2015-01-27 21:26 UTC, Jakob Unterwurzacher
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jakob Unterwurzacher 2015-01-27 21:26:43 UTC
Created attachment 10673 [details]

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


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.
Comment 1 Jakob Unterwurzacher 2015-01-27 21:30:17 UTC
$ uname -r
Comment 2 Björn Jacke 2024-01-07 13:14:50 UTC
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.