Created attachment 10061 [details] tcpdump pcap file. Time stamps prior to epoch are wrapped. It is observed that xSMB server is maintaining and providing right time stamp details but cifs client is unable to display them in the proper way. Read the below command line output for more details. [root@xsmbRHEL7LinuxVM Azureshare]# TESTFILE=timestamp-test1.txt [root@xsmbRHEL7LinuxVM Azureshare]# touch -t 196001010101 $TESTFILE tat $TESTFILE ts=`stat -c %X $TESTFILE` [root@xsmbRHEL7LinuxVM Azureshare]# stat $TESTFILE File: ‘timestamp-test1.txt’ Size: 0 Blocks: 0 IO Block: 16384 regular empty file Device: 24h/36d Inode: 5177345 Links: 1 Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:cifs_t:s0 Access: 1960-01-01 01:01:00.000000000 -0500 Modify: 1960-01-01 01:01:00.000000000 -0500 Change: 2014-06-26 19:25:10.370328764 -0400 Birth: - [root@xsmbRHEL7LinuxVM Azureshare]# ts=`stat -c %X $TESTFILE` [root@xsmbRHEL7LinuxVM Azureshare]# echo $ts -315597540 [root@xsmbRHEL7LinuxVM Azureshare]# cd / [root@xsmbRHEL7LinuxVM /]# umount /Azureshare [root@xsmbRHEL7LinuxVM /]# mount -t cifs //Azurefileserver/sharename /Azureshare -o vers=2.1,username=myusername,password='mypassword',dir_mode=0777,file_mode=0777 [root@xsmbRHEL7LinuxVM /]# cd - /Azureshare [root@xsmbRHEL7LinuxVM Azureshare]# ts=`stat -c %X $TESTFILE` [root@xsmbRHEL7LinuxVM Azureshare]# stat $TESTFILE File: ‘timestamp-test1.txt’ Size: 0 Blocks: 0 IO Block: 16384 regular empty file Device: 24h/36d Inode: 5177345 Links: 1 Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:cifs_t:s0 Access: 60415-05-28 07:37:10.955161600 -0400 Modify: 60415-05-28 07:37:10.955161600 -0400 Change: 2014-06-26 19:25:10.370328700 -0400 Birth: - [root@xsmbRHEL7LinuxVM Azureshare]# echo $ts 1844358809830 [root@xsmbRHEL7LinuxVM Azureshare]# uname -a Linux xsmbRHEL7LinuxVM 3.15.1 #1 SMP Fri Jun 20 18:37:34 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux [root@xsmbRHEL7LinuxVM Azureshare]# Part of information from the attached pcap file: We can see that client is sending right information to the xSMB server. ^^^^^ - SMB2: C SET INFORMATION (0x11), FID=0xFFFFFFFF0000004D, Class=FileBasicInformation (4) - FileInfo: - FileBasicInformation: CreationTime: No Time Specified (0) LastAccessTime: 01/01/1960, 06:01:00.000000 UTC LastWriteTime: 01/01/1960, 06:01:00.000000 UTC ChangeTime: 06/26/2014, 23:25:10.370328 UTC + FileAttributes: Reserved: 4294936576 (0xFFFF8800) After remounting the share server is providing the same timestamp information on request. ******** - SMB2: R QUERY INFORMATION (0x10), File=timestamp-test1.txt@#77 - FileInfo: - FileAllInformation: - BasicInformation: CreationTime: 06/26/2014, 23:25:10.347491 UTC LastAccessTime: 01/01/1960, 06:01:00.000000 UTC LastWriteTime: 01/01/1960, 06:01:00.000000 UTC ChangeTime: 06/26/2014, 23:25:10.370328 UTC
This looks like a server bug. cifs.ko is sending a date of 1960 in frame 10 which seems correct, and the server is returning the incorrect time (year 2014 instead of 1960) in frames 21 and 24. Samba server has a similar problem see bug 7771 (https://bugzilla.samba.org/show_bug.cgi?id=7771) Note that cifs vfs (cifs.ko) did fix a problem with negative time stamps recently (now upstream in 3.17 kernel). See https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/cifs?id=2ae83bf93882d1ec0cd775c489bd1bee611f792e