|Summary:||cp -p does not copy mtime to CIFS share|
|Product:||[Fedora] Fedora||Reporter:||Wojciech Pilorz <wpilorz>|
|Component:||kernel||Assignee:||Jeff Layton <jlayton>|
|Status:||CLOSED UPSTREAM||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||F8||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-08-07 12:42:58 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Wojciech Pilorz 2007-09-25 14:40:53 UTC
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 126.96.36.199-49.fc6, CIFS Version 1.49, coreutils-5.97-12.5.fc6.i386 How reproducible: always 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)
Comment 1 Jeff Layton 2007-11-20 01:16:26 UTC
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?
Comment 2 Jeff Layton 2008-01-15 11:28:32 UTC
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.
Comment 3 Wojciech Pilorz 2008-01-24 22:40:58 UTC
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)
Comment 4 Bug Zapper 2008-04-04 07:35:58 UTC
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. http://fedoraproject.org/wiki/LifeCycle/EOL 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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
Comment 5 Wojciech Pilorz 2008-04-04 21:05:43 UTC
Last time I have checked on Fedora8 system it still did have the problem. See my Comment#3
Comment 6 Jeff Layton 2008-04-18 19:59:52 UTC
I've been able to reproduce this against windows: 6 0.008533 10.11.231.229 -> 10.11.231.44 SMB NT Create AndX Request, Path: \p1\p2\p3\svc-recv-error.patch 7 0.009599 10.11.231.44 -> 10.11.231.229 SMB NT Create AndX Response, FID: 0xc00f ...file is created... 8 0.011168 10.11.231.229 -> 10.11.231.44 SMB Write AndX Request, FID: 0xc00f, 827 bytes at offset 0 9 0.012117 10.11.231.44 -> 10.11.231.229 SMB Write AndX Response, FID: 0xc00f, 827 bytes ...write some data to it... 10 0.013129 10.11.231.229 -> 10.11.231.44 SMB Trans2 Request, SET_PATH_INFO, Path: \p1\p2\p3\svc-recv-error.patch 11 0.014082 10.11.231.44 -> 10.11.231.229 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 10.11.231.229 -> 10.11.231.44 SMB Close Request, FID: 0xc00f 13 0.015803 10.11.231.44 -> 10.11.231.229 SMB Close Response, FID: 0xc00f ...we close the file... 15 5.823131 10.11.231.229 -> 10.11.231.44 SMB Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: \p1\p2\p3\svc-recv-error.patch 16 5.824217 10.11.231.44 -> 10.11.231.229 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 7 Jeff Layton 2008-04-21 18:56:48 UTC
I've done a bit of reading on the spec... The SMB_COM_CLOSE call has a LastWriteTime field (ugh). You can set it to whatever you like, but there are a couple of special values: 0 == leave it to the server -1 == now documentation on this is sketchy though. The current code sends -1, but I experimented with sending 0, and there was no difference. I suspect that the problem is the server is resetting the mtime on close for either value.
Comment 8 Wojciech Pilorz 2008-04-21 23:51:30 UTC
(In reply to comment #7) > I've done a bit of reading on the spec... > > The SMB_COM_CLOSE call has a LastWriteTime field (ugh). You can set it to > whatever you like, but there are a couple of special values: > > 0 == leave it to the server > -1 == now > > documentation on this is sketchy though. The current code sends -1, but I > experimented with sending 0, and there was no difference. I suspect that the > problem is the server is resetting the mtime on close for either value. > There was not such problem with smbfs filesystem (now disabled in kernel builds) Maybe you could compare smbfs code to cifs?
Comment 9 Jeff Layton 2008-04-22 00:14:10 UTC
Looks like smbfs posts the mtime of the file to the server on close. We may be able to do the same here. I'll have a look at it soon...
Comment 10 Jeff Layton 2008-04-23 13:11:41 UTC
It's definitely the close that's affecting the file. I wrote a small program to open and create a file, write a small amount to it, set the mtime on it and then wait until I hit a key and close the file. The time looks correct on the server after the futimes() call. It's not until the close() that it gets clobbered. There is a LastWriteTime field in the SMB_COM_CLOSE call. This is what smbfs uses, but the problem there is that it's an old DOS-based time -- 32 bit value with 2s resolution. I'm worried that using that might lead to problems in the future. Also, using that assumes that the mtime recorded in the inode on the client is what it should be on the server. That's not necessarily the case -- it's possible that that time has been modified by another client, and setting it to what we think it should be on close might leave it set to the wrong value.
Comment 11 Jeff Layton 2008-04-29 12:52:19 UTC
Guenter Kukkukk has posted a patch upstream that seems to fix this. It makes it so that cifs_setattr sets the file time using SET_FILE_INFO rather than SET_PATH_INFO when the file is already open for write. This seems to work around the behavior of windows here (and is probably a reasonable thing to do). There's still discussion going on upstream about whether this fix is comprehensive enough (it could still break in some cases), and whether we need to do more to ensure that old pre-NT4 servers still work as expected. So we're not close to a patch upstream yet, but I think we at least have an understanding of the problem.
Comment 12 John L Magee 2008-07-12 18:18:00 UTC
Just to be clear, this still fail with the latest FC9 connected to both Windows XP and Windows Server 2003 shares. See following: [root@jlmt61pfc ~]# uname -r 188.8.131.52-76.fc9.x86_64 [root@jlmt61pfc ~]# yum list coreutils Loaded plugins: priorities, refresh-packagekit Installed Packages coreutils.x86_64 6.10-27.fc9 installed [root@jlmt61pfc ~]# mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sda2 on /boot type ext3 (rw) tmpfs on /dev/shm type tmpfs (rw) /dev/sda1 on /media/sda1 type fuseblk (rw,allow_other,blksize=4096) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) //172.23.20.9/c$ on /mnt/jlm32 type cifs (rw,mand) [root@jlmt61pfc ~]# ls -l /home/jlmagee/Download/ total 36 -rw-rw-r-- 1 jlmagee jlmagee 30385 2007-05-27 16:08 bootable-raid1.pdf -rwxrwxrwx 1 jlmagee jlmagee 126 2008-02-15 08:33 CAQH Online Eligibility and Benefits Inquiry.url [root@jlmt61pfc ~]# cp -p /home/jlmagee/Download/* /mnt/jlm32/temp/ cp: overwrite `/mnt/jlm32/temp/bootable-raid1.pdf'? y cp: overwrite `/mnt/jlm32/temp/CAQH Online Eligibility and Benefits Inquiry.url'? y [root@jlmt61pfc ~]# ls -l /mnt/jlm32/temp/bootable-raid1.pdf -rw-rw-r-- 1 jlmagee jlmagee 30385 2008-07-12 14:08 /mnt/jlm32/temp/bootable-raid1.pdf [root@jlmt61pfc ~]# [root@jlmt61pfc ~]# mkdir /mnt/msrv3 [root@jlmt61pfc ~]# mount -t cifs -o username=jlmagee //172.16.90.3/c$ /mnt/msrv3 Password: [root@jlmt61pfc ~]# cp -p /home/jlmagee/Download/bootable-raid1.pdf /mnt/msrv3/temp/ cp: overwrite `/mnt/msrv3/temp/bootable-raid1.pdf'? y [root@jlmt61pfc ~]# ls -l /mnt/msrv3/temp/bootable-raid1.pdf -rw-rw-r-- 1 jlmagee jlmagee 30385 2008-07-12 14:11 /mnt/msrv3/temp/bootable-raid1.pdf [root@jlmt61pfc ~]#
Comment 13 Jeff Layton 2008-07-12 18:26:44 UTC
I've pushed a patchset upstream to fix this, but it's not likely to be incorporated until 2.6.27. Patchset is available here if you wish to build a kernel with it and test it: http://www.nabble.com/-PATCH-0-7---CIFS--clean-up-cifs_setattr-and-fix-setting-of-mtimes-to17428822.html
Comment 14 Jeff Layton 2008-08-07 12:42:58 UTC
At long last, this patchset has been committed to the upstream cifs-2.6 git tree. It should eventually get pushed to mainline kernels, probably for 2.6.27 (or maybe 2.6.28). Closing this bug with a resolution of UPSTREAM...