Bug 443395 - cp -p does not copy mtime to CIFS share
Summary: cp -p does not copy mtime to CIFS share
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.3
Hardware: i686
OS: Linux
Target Milestone: rc
: ---
Assignee: Jeff Layton
QA Contact: Martin Jenner
Whiteboard: bzcl34nup
Keywords: Reopened
Depends On: 305191
Blocks: 445643
TreeView+ depends on / blocked
Reported: 2008-04-21 10:59 UTC by Jose Plans
Modified: 2018-10-19 22:09 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2009-01-20 20:23:52 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:0225 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.3 kernel security and bug fix update 2009-01-20 16:06:24 UTC

Description Jose Plans 2008-04-21 10:59:38 UTC
+++ This bug was initially created as a clone of Bug #305191 +++

Description of problem:
When a file is copied to a CIFS share (tested with W2K and NT4),
mtime is not copied from original file.
On the other hand, tar x does copy mtime.

Version-Release number of selected component (if applicable):
kernel, CIFS Version 1.49,

How reproducible:

Steps to Reproduce:
1. mount a CIFS share, say to /mnt/cifs1
2. cd /tmp; echo 123 > f123; touch -d '2005-01-02 11:00' f123
3. cp -p f123 /mnt/cifs1
4. env LANG=C ls -l --full-time f123 /mnt/cifs1/f123
Actual results:
/mnt/cifs1/f123 has mtime taken from current time

Expected results:
/mnt/cifs1/f123 should have mtime 2005-01-02

Additional info:
The difference between tar and cp is that tar 
sets mtime on closed file using utime on destination pathname
(after it is closed),
while cp -p calls utimes on opened filehandle
using /proc/self/fd/n (then handle n is closed)

-- Additional comment from jlayton@redhat.com on 2007-11-19 20:16 EST --
This works for me on F8, so I assume that something has changed upstream to fix
this. Can you restest on a more recent kernel (preferably something 2.6.23-ish)
and let me know if this still an issue?

-- Additional comment from jlayton@redhat.com on 2008-01-15 06:28 EST --
No response. Closing as CURRENTRELEASE since my testing indicates that this is
no longer a bug. Please reopen if you're still able to reproduce this.

-- Additional comment from wpilorz@gmail.com on 2008-01-24 17:40 EST --
I still get this problem on Fedora 8 machine (i686 kernel, P4 CPU)
when using the following
cd /mnt/winshare/mydirectory
cp -vip existing_file new_file

Now new_file get mtime from the time the  cp is run, rather than
from existing_file.

The mounted share is exported from a Windows server (Windows 2000 or 2003
Advanced Server, I am not sure at the moment)

-- Additional comment from fedora-triage-list@redhat.com on 2008-04-04 03:35 EST --
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

-- Additional comment from wpilorz@gmail.com on 2008-04-04 17:05 EST --
Last time I have checked on Fedora8 system it still did have the problem.
See my Comment#3

-- Additional comment from jlayton@redhat.com on 2008-04-18 15:59 EST --
I've been able to reproduce this against windows:

  6   0.008533 -> SMB NT Create AndX Request, Path:
  7   0.009599 -> SMB NT Create AndX Response, FID:

...file is created...

  8   0.011168 -> SMB Write AndX Request, FID:
0xc00f, 827 bytes at offset 0
  9   0.012117 -> SMB Write AndX Response, FID:
0xc00f, 827 bytes

...write some data to it...

 10   0.013129 -> SMB Trans2 Request, SET_PATH_INFO,
Path: \p1\p2\p3\svc-recv-error.patch
 11   0.014082 -> SMB Trans2 Response, SET_PATH_INFO

...here we set the "last write" and "last access" times to the timestamp of the
source file. Server returns success....

 12   0.015010 -> SMB Close Request, FID: 0xc00f
 13   0.015803 -> SMB Close Response, FID: 0xc00f

...we close the file...

 15   5.823131 -> SMB Trans2 Request,
QUERY_PATH_INFO, Query File All Info, Path: \p1\p2\p3\svc-recv-error.patch
 16   5.824217 -> SMB Trans2 Response, QUERY_PATH_INFO

...now QUERY_PATH_INFO (I did a stat against the file on the client). This info
has the "last write" time set to the current time -- *not* what was set in the
SET_PATH_INFO call above. Apparently the CLOSE call is affecting the "last
write" time somehow.

I suspect that the server is buffering the write until the close call comes in
and then that is clobbering the time we're setting. We may be able to mitigate
this by forcing it to flush the data before the SET_PATH_INFO call, but I'll
need to research it a bit...

Comment 2 Jeff Layton 2008-05-01 18:13:09 UTC
I've put an *experimental* patch for this in the RHEL5 kernels on my people page:


It seems to fix the problem for me, but is still being debated upstream. It
would be helpful if the customer here could test this as well and let us know
whether it seems to fix the problem for them.

Comment 3 Jeff Layton 2008-05-02 11:20:57 UTC
Guenter Kukkukk pointed out that his experimental patch does not currently
handle Windows NT4 correctly, and may also not handle Windows9x correctly. The
patch will probably be respun, but should work for Win2k and later.

Comment 4 Jeff Layton 2008-05-20 12:15:44 UTC
I've got a new set of 7 patches that does some breaks up cifs_setattr into
multiple functions and also fixes this problem. The patchset depends on another
patchset that I've sent upstream but hasn't yet been committed.

Once that patchset is in place, I'll post the new patchset and we can see about
getting it into RHEL.

Comment 5 RHEL Product and Program Management 2008-06-19 14:24:47 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 7 Jeff Layton 2008-07-02 17:24:46 UTC
I've gone ahead and added the patchset to fix this to the test kernels on my
people page. These particular kernels are very bleeding-edge and have a fairly
massive CIFS update + this set of patches. If the customer who reported this
could test these kernels somewhere non-critical, then it would be helpful:


Comment 9 Don Zickus 2008-09-13 01:46:52 UTC
in kernel-2.6.18-113.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Comment 12 Wojciech Pilorz 2008-11-05 14:56:07 UTC
I have tried kernel 2.6.18-121.el5.jtltest.53 [i686] on a P4 machine
running CentOS 5 (fully updated).

cp -p seems to set time fine up to 1microsecond resolution on shares exported from NT4 workstaton, XP workstation Pro, Windows Server 2000 and 2003.

( sub-microsecond part of modification time is not copied,
  but who cares ...)

The CIFS operations I tried today did not reveal any problems.

I will do more testing on Friday,

so far seems very good. Thanks!

Comment 14 errata-xmlrpc 2009-01-20 20:23:52 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.