Bug 8437

Summary:	Timestamps are not preserved when copying files larger than 0 bytes to awindows share using 'cp -pa' from recent coreutils
Product:	File System	Reporter:	GregW (kb)
Component:	CIFS	Assignee:	Steve French (sfrench)
Status:	RESOLVED CODE_FIX
Severity:	normal	CC:	kernel, protasnb, sfrench, shirishp
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.21	Subsystem:
Regression:	---	Bisected commit-id:

Description GregW 2007-05-06 08:28:55 UTC

Most recent kernel where this bug did *NOT* occur:
Distribution:
Hardware Environment:
Software Environment:
Problem Description:

Steps to reproduce:
1. cp -pa (or -a) (or -p) (or --preserve=timestamps)
2. ls -l /mnt/share/file
3. file has the current system time for the date stamps
4. cp -pa nullfile /mnt/share
5. ls -l /mnt/share/nullfile
6. nullfile has correct date stamps

Actual Results:  
copied file is stamped as current date/time
null file has the correct (source) files date/time stamps

Expected Results:  
obvious: cp should preserve datestamps ;-)

Comment 1 Daniel Drake 2007-05-06 09:16:48 UTC

Downstream bug https://bugs.gentoo.org/173779

With recent versions of coreutils, cp performs syscalls on the destination file
in this order:

open()
write() [for files larger than 0 bytes]
utimes()
close()

With coreutils-5.91 and older, the order was different:

open()
write()
close()
utimes()

CIFS seems to update the file modification time upon close() if any previous
writes took place, overwriting the value put in place by the earlier utimes().
However, POSIX effectively says that such fields should be updated before the
utimes() call, not during close():

  All fields that are marked for update shall be updated [...] before a utimes()
is successfully performed on the file;

http://www.opengroup.org/austin/mailarchives/ag-review/msg01971.html

This exact bug also existed in the NFS client filesystem, and has been fixed:
http://bugzilla.kernel.org/show_bug.cgi?id=6127

Comment 2 Daniel Drake 2007-05-06 09:17:34 UTC

This bug has been reproduced on 2.6.21

Comment 3 Steve French 2009-01-24 20:24:01 UTC

Have you tried this on 2.6.27 on later ... I would expect it to work ok

Comment 4 Shirish Pargaonkar 2009-01-24 21:01:16 UTC

Actually, I am confused about steps 1 and 4 listed in comment #1.

What is being copied in step 1, I see only cp -pa command
and what is nullfile in step 4, a special file like /dev/null or just any file 
named nullfile?

Comment 5 Shirish Pargaonkar 2009-02-01 17:56:15 UTC

This is not a bug any more, I verified with cifs on the kernel 2.6.27.8

# ls -l autoinst.xml
-rw-r--r-- 1 root root 39795 Jan 26 21:45 autoinst.xml

# date
Sun Feb  1 19:49:23 CST 2009

# cp autoinst.xml /mnt/smb_a
# ls -l /mnt/smb_a/autoinst.xml
-rwxrwSrwx 1 root root 39795 Feb  1 19:47 /mnt/smb_a/autoinst.xml

# cp -pa autoinst.xml /mnt/smb_a/ai.xml
# ls -l /mnt/smb_a/ai.xml
-rwxrwSrwx 1 root root 39795 Jan 26 21:45 /mnt/smb_a/ai.xml

This bug can be closed.