Bug 804121

Summary: The smbclient(1) tar -T command does not preserve some file modification times during Daylight Savings time
Product: Red Hat Enterprise Linux 5 Reporter: Todd Zervas <todd>
Component: samba3xAssignee: Guenther Deschner <gdeschner>
Status: CLOSED NOTABUG QA Contact: qe-baseos-daemons
Severity: low Docs Contact:
Priority: unspecified    
Version: 5.8CC: prc, sbose, todd
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-02 08:47:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Todd Zervas 2012-03-16 15:13:11 UTC
Description of problem:

The smbclient(1) tar -T command does not preserve file modification
times correctly during Daylight Savings time (DST) for files with file
modification time stamps within Standard time (not DST).  During DST the
tar command adds two hours to each file modification time that falls
within the standard time period in the archive when 'x' (extracting)
a tar archive to an SMB share.  During DST the tar command subtracts
one hour when 'c' (creating/downloading) files with file modification
times within the standard time period into a tar archive from the SMB share.

I've tested this using two different SMB servers.  The servers both
identified themselves as: OS=[EMC-SNAS:T5.6.51.320].  Both servers are
located in the same time zone as the client.

Version-Release number of selected component (if applicable):

smbclient versions: Version 3.5.10-0.107.el5 and Version 3.0.33-3.38.el5_8 are both affected (samba and samba3x): samba3x-client.x86_64 3.5.10-0.107.el5, samba-client.x86_64 3.0.33-3.38.el5_8

How reproducible: repeatable, easy to reproduce using the steps given.

Steps to Reproduce:

1. Ensure the system clock is set to Daylight Savings Time (for my tests
the RHEL 5.8 server is in PST8PDT).

2. Create one or more test files.

3. Use touch to assign them a file modification time within a standard
time period (i.e. not daylight savings time), for example: touch -t
201201160000.00 files ...

4. Create a tar archive of the files: tar -cf <archive> files ...

5. Use smbclient to upload the files to a SMB share: smbclient
<host>/<share> -Tx <archive>

6. Note the times on the share are all two hours later then assigned in
step #3 above.

7. Retrieve the files using: smbclient <host>/<share> -Tc <new archive>

8. Obtain a new archive from the share and note the times within: tar -tvf <new archive>.
  
Actual results:

The times in the new archive are one hour earlier then the share and
are one hour later then the original archive.  

Expected results:

The times in the two archives should match.

Additional info:

Comment 1 Guenther Deschner 2012-03-22 14:55:06 UTC
Hello,

Can you reproduce this behaviour also against non-EMC cifs servers like samba?

Thanks

Comment 2 Todd Zervas 2012-03-23 14:03:49 UTC
I do not have access to a samba server.  I tested a Windows XP server (OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]) and it works correctly.  The time correction value is applied in step #5 and is applied again in step #7 which results in times matching between the two archives (as expected).

Comment 3 Guenther Deschner 2012-03-23 14:10:27 UTC
Ok, thank you. 

In that case I would strongly suspect that your EMC NAS server does something wrong - you just tested that the Samba client tool works correctly with a "standard" Windows CIFS server. 

You should contact EMC and ask them for a solution or a possible workaround.

Comment 4 Sumit Bose 2012-04-27 10:09:48 UTC
Did you get any feedback from EMC about this issue?

Comment 5 Todd Zervas 2012-04-30 20:11:42 UTC
EMC referred me to their problem PR00012809.  I will need to update my EMC SAN device to apply this fix.

PR00012809 Daylight savings changes cause all files to be transferred

PROBLEM:

In a heterogeneous environment (e.g. transferring from Microsoft Windows to UNIX), after daylight saving time changes, all files are transferred even if the check type is based on the modify time of the files and those files have NOT changed.
 
This is due to a well-known Microsoft Windows time implementation feature with a less well-known solution. Here are some interesting resources on the issue:
 
The article at this URL: http://www.codeproject.com/datetime/dstbugs.asp
How PERL works around the issue click here.

FIX:

It turns out that NTFS actually stores the file times in UTC. It is Microsoft Windows display of these times that is incorrect. Microsoft Windows applies the UTC bias for the local timezone at the time the conversion call is made rather than at the time represented by the UTC value.
 
This causes the displayed time to change whenever a standard to daylight or daylight to standard time transition occurs. Our previous code attempted to make the displayed times be the same when files were transferred from Microsoft Windows to UNIX or UNIX to Microsoft Windows.
 
Made the code changes to do the conversion simply by adding or subtracting the time between the two epochs. This should eliminate the transfer of all the files when the time transition occurs.
 
One complication is that the FAT file system does store the file times as local time so there may be a screw up if transferring form NTFS to FAT (or not - this needs testing). It is possible to determine if the file system used local or UTC time, but the call to check the file system type multiplies the time required to do the conversion by a factor of 60 (not 60% but 60 times), so we won't be doing that. We will just assume that all file times are in UTC.

Comment 6 Todd Zervas 2012-05-09 16:46:20 UTC
Also works correctly on OS=[Windows Server 2003 R2 3790 Service Pack 2] Server=[Windows Server 2003 R2 5.2].

Comment 7 Sumit Bose 2012-06-01 08:22:32 UTC
This does not seem to be a samba issue at all. Can we close this bug?

Comment 8 Todd Zervas 2012-06-02 03:34:19 UTC
Yes, you can close this bug.