Oddity: When should Mtime and Ctime be updated for SMB servers?

Oddity: When should Mtime and Ctime be updated for SMB servers?

[ronnie sahlberg]

List, All,

I was trying to investigate why we had a regression in xfstests
generic/313 and found something odd about when Windows updates the
timestamps for a file.

What the test performs is basically:
1, Create a file
2, Set file size to 0
3, explicitly set the ctime and mtime to the current time of the client
4, read the timestamps back  and verify they are set correctly
delay for 1 second
5, write to the file
6, truncate the file back to 0
7, and check the timestamps again, they should have been updated due to 5,6

This works as expected IF step 3 uses a compound, i.e. a different
handle (how cifs.ko used to work, since this particular kernel api is
path based)

However, IF step 3 uses the same handle from step 1 instead of a
compound then this no longer works. The timestamps are no longer
updated in steps 5,6.

What are the semantics for when these timestamps should be updated by
a write or a truncate?
And why does it matter if step 4 is a compound with
create/setinfo/close versus if it just uses the same handle from the
create in step 1?


Since the traces are tiny I will include them in ASCII form. Anyone
that wants the actual pcap traces to view them in wireshark, just
email me and I will send them.


Original cifs.ko behavior:
====================
    1 0.000000000 SMB2 Create Request File: bar
    2 0.001809747 SMB2 Create Response File: bar
    8 0.004397925 SMB2 Flush Request File: bar
    9 0.013682200 SMB2 Flush Response
   11 0.014561091 SMB2 SetInfo Request
FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: bar
   12 0.014957578 SMB2 SetInfo Response
   14 0.015851218 SMB2 Create Request File: bar;SetInfo Request
FILE_INFO/SMB2_FILE_BASIC_INFO;Close Request
   15 0.016358273 SMB2 Create Response File: bar;SetInfo Response;Close Response
   17 0.017253133 SMB2 Create Request File: bar;GetInfo Request
FILE_INFO/SMB2_FILE_ALL_INFO;Close Request
   18 0.017736416 SMB2 Create Response File: bar;GetInfo Response;Close Response
   20 1.019048674 SMB2 Write Request Len:22 Off:0 File: bar
   21 1.020140390 SMB2 Write Response
   23 1.021696732 SMB2 SetInfo Request
FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: bar
   24 1.022446473 SMB2 SetInfo Response
   26 1.024223917 SMB2 Create Request File: bar;GetInfo Request
FILE_INFO/SMB2_FILE_ALL_INFO;Close Request
   27 1.025163155 SMB2 Create Response File: bar;GetInfo Response;Close Response
   29 1.028479545 SMB2 Close Request File: bar
   30 1.029246502 SMB2 Close Response

In this case, packet 14 is the compound used to set the timestamps.
Packet 17 reports that the timestamps were set to the values in 14.
Now there is a one second delay and we write to the file, truncate it
and then read back the timestamps and the timestamps have incremented.

New cifs.ko behavior:
=================
    4 0.003062951 SMB2 Create Request File: bar
    5 0.004362998 SMB2 Create Response File: bar
    7 0.005922755 SMB2 Flush Request File: bar
    8 0.009779700 SMB2 Flush Response
   10 0.011293505 SMB2 SetInfo Request
FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: bar
   11 0.012076033 SMB2 SetInfo Response
   12 0.013181837 SMB2 SetInfo Request FILE_INFO/SMB2_FILE_BASIC_INFO File: bar
   13 0.014015512 SMB2 SetInfo Response
   14 0.015743571 SMB2 Create Request File: bar;GetInfo Request
FILE_INFO/SMB2_FILE_ALL_INFO;Close Request
   15 0.016904597 SMB2 Create Response File: bar;GetInfo Response;Close Response
   17 1.018801828 SMB2 Write Request Len:22 Off:0 File: bar
   18 1.019773131 SMB2 Write Response
   20 1.021448036 SMB2 SetInfo Request
FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: bar
   21 1.022202409 SMB2 SetInfo Response
   23 1.023990091 SMB2 Create Request File: bar;GetInfo Request
FILE_INFO/SMB2_FILE_ALL_INFO;Close Request
   24 1.025077567 SMB2 Create Response File: bar;GetInfo Response;Close Response
   26 1.028801682 SMB2 Close Request File: bar
   27 1.029697708 SMB2 Close Response

The only difference here is that in packet 12, where we set the
timestamps, we no longer use a new handle in a c reate/setinfo/close
compound but instead
use the existing handle that is already open.
In this case the timestamps are no longer updated by the write or
truncate in packets 17 and 20.


Regards
Ronnie Sahlberg