Bug 10686 - Timestamps prior to epoch are wrapped. (Observed on SMB 2.1 and Linux 3.15.1)
Summary: Timestamps prior to epoch are wrapped. (Observed on SMB 2.1 and Linux 3.15.1)
Status: RESOLVED FIXED
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 2.6
Hardware: x64 Linux
: P5 normal
Target Milestone: ---
Assignee: Steve French
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-01 21:54 UTC by Srikanth Myakam (mail address dead)
Modified: 2014-10-19 00:18 UTC (History)
1 user (show)

See Also:


Attachments
tcpdump pcap file. (14.54 KB, application/octet-stream)
2014-07-01 21:54 UTC, Srikanth Myakam (mail address dead)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Srikanth Myakam (mail address dead) 2014-07-01 21:54:02 UTC
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
Comment 1 Steve French 2014-10-19 00:18:29 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