copying data to a mounted windows 2003 server share causes the current date/time to be used as the date stamp. copying a null file to the same share, the date/time attributes are preserved! Reproducible: Always 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 ;-) these url's maybe of interest to you: http://groups.google.co.uk/group/gnu.utils.bug/browse_thread/thread/c58e1c861c7bee0/88c87de44a1cd2df?lnk=st&q=cp+not+preserving+date&rnum=4&hl=en#88c87de44a1cd2df https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/57317 and my gentoo community post: http://forums.gentoo.org/viewtopic-t-551404-start-0-postdays-0-postorder-asc-highlight-gregw.html I dont know if this is a gentoo/samba/linux bug, it maybe specific to windows 2003 serrver, but this behaviour does the same on two different site that use windows 2003/gentoo samba servers. Can someone in the community test this and report back. tried using kernel-2.6.17-r1 as 2.6.16 has bugs with opening files. tried using kernel-2.6.19 tried using kernel-2.6.20 downgraded samba to 3.0.22-r3 downgraded fileutils emerge --info gentoo ~ # emerge --info Portage 2.1.2.2 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.17 i686) ================================================================= System uname: 2.6.17 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System release 1.12.9 Timestamp of tree: Sun, 08 Apr 2007 02:20:01 +0000 ccache version 2.4 [enabled] dev-java/java-config: 1.2.11-r1 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ ftp://ftp6.uni-erlangen.de/pub/mirrors/gentoo ftp://vlaai.snt.ipv6.utwente.nl/pub/os/linux/gentoo/ http://vlaai.snt.ipv6.utwente.nl/pub/os/linux/gentoo/ http://ftp6.uni-erlangen.de/pub/mirrors/gentoo" LC_ALL="en_GB" LINGUAS="en_GB es" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X alsa arts audiofile berkdb bitmap-fonts cairo cdparanoia cdr cli cracklib crypt cups dbus dri dvd dvdr eds emboss encode esd fam firefox foomaticdb fortran gdbm gif gimp-print gpm gstreamer hal iconv ipv6 isdnlog jpeg kde kerberos ldap libg++ mad midi mikmod mp3 mpeg ncurses nls nptl nptlonly ogg opengl oss pam pcre perl png ppds pppd python qt qt3 qt4 quicktime readline reflection samba sdl session slp smime spell spl ssl tcpd truetype truetype-fonts type1-fonts unicode usb vorbis win32codecs winbind x86 xml xorg xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB es" USERLAND="GNU" VIDEO_CARDS="nv vga fbdev i810" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
For starters, /mnt/share is what? samba mount, CIFS mount, NFS mount, something else? What's your coreutils version?
(In reply to comment #1) > For starters, /mnt/share is what? samba mount, CIFS mount, NFS mount, something > else? did you read my post? "data to a mounted windows 2003 server share" dont wanna do that via nfs ;-) Its a samba share which i've been mounting without issue for a long time. started with samba-3.0.24, have downgraded to samba-3.0.22-r3 still have same problems What's your coreutils version? > Currently using sys-apps/coreutils-6.7-r1 I have just copied some files to a share on a win xp-sp2 machine and I get the same behaviour. Im just settign up a win xp-sp2 system in a vmware machine to test thsi without all the recent ms updates. Cheers GregW
(In reply to comment #2) > (In reply to comment #1) > > For starters, /mnt/share is what? samba mount, CIFS mount, NFS mount, something > > else? > > did you read my post? > "data to a mounted windows 2003 server share" ; its a CIFS mount > > dont wanna do that via nfs ;-) > > Its a samba share which i've been mounting without issue for a long time. > started with samba-3.0.24, have downgraded to samba-3.0.22-r3 still have same > problems > > What's your coreutils version? > > > Currently using sys-apps/coreutils-6.7-r1 > > I have just copied some files to a share on a win xp-sp2 machine and I get the > same behaviour. Im just settign up a win xp-sp2 system in a vmware machine to > test thsi without all the recent ms updates. > > Cheers > GregW >
(In reply to comment #2) > did you read my post? > "data to a mounted windows 2003 server share" > > dont wanna do that via nfs ;-) Yeah, sure I did read your post. It's not even clear what's server and what's client. You are sharing something on W2K3 and mounting it on Linux? If you can reproduce this when you mount the share via CIFS on 2.6.19+ kernel, reopen this bug.
> You are sharing something on W2K3 and mounting it on Linux? If you can > reproduce this when you mount the share via CIFS on 2.6.19+ kernel, reopen this > bug. > Thanks Jakub Gentoo box is client Windows 2003 box is the server yes, I can reproduce this with a 2.6.19 kernel, 2.6.20 kernel (which is the one i first noticed thsi behaviour on) and a 2.6.20.4 kernel. I'll post back after the vmware machine is running and let you know if the same behaviour exists. Cheers GregW
It's not really needed to test on VMWare, just mount the thing via CIFS; samba has nothing to do with this, it's kernel smbfs you are using (or finally post the output of `mount` if it's not, really tired of guessing).
(In reply to comment #6) (or finally post > the output of `mount` if it's not, really tired of guessing). > her ya go; /dev/hda3 on / type ext3 (rw,noatime) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec) udev on /dev type tmpfs (rw,nosuid) devpts on /dev/pts type devpts (rw,nosuid,noexec) /dev/hda1 on /boot type ext3 (rw,noatime) none on /dev/shm type tmpfs (rw) /dev/hdb1 on /home/ftp type ext3 (rw,noatime) usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) //celera-san/HOME on /mnt/cel type cifs (rw,mand,noexec,nosuid,nodev) //w2k3-server/Shared on /mnt/share type cifs (rw,mand) celera-san is the company celera SAN system, this one behaves properly and does preserve the data stamps w2k3-server is the win 2003 server that gives me the problems hope this helps ya? btw, this is the invocation in /etc/fstab (all one one line is fstab //celera-san/cel /mnt/P cifs noauto,user,credentials=/root/.smbcredentials,domain=celera.dom,uid=myuser,gid=mygroup,fil$ //w2k3-server/Shared /mnt/lee cifs noauto,credentials=/root/.smbcredentials,uid=myuser,gid=mygroup,file_mode=0775,dir_mode=0775 Hope this helps? IRT your comment about vmware, why would this not be worth trying? what i'm trying to verify is where the problem lies. as mentioned in my first post, this may not be a gentoo/linux/samba issue. My money is on summut in in windows causing this. The 2003 server is fully patched against a managed WSUS server. Once its ruled out (or in) it help all of us identify where the problem is. I've seen many bug posts stall cos the devs say they can test it as they dont have the hardware/software/resources to do it. I was hoping that I was being helpful with my suggestion. Let me know if you need anymore info. Cheers GregW
Sounds like an issue with the remote end if one CIFS share works fine and another doesn't. Can you experiment modifying the mtime/atimes of files on both mounts using the -a and -m options to touch?
(In reply to comment #8) > Sounds like an issue with the remote end if one CIFS share works fine and > another doesn't. Can you experiment modifying the mtime/atimes of files on both > mounts using the -a and -m options to touch? > OK, using the following on the remote (windows 2003 server) give the following touch Bellagio-Fountain.jpg -m -t 198412121015.00 stat Bellagio-Fountain.jpg File: `Bellagio-Fountain.jpg' Size: 370206 Blocks: 728 IO Block: 16384 regular file Device: 10h/16d Inode: 79777 Links: 1 Access: (3767/-rwxrwSrwt) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2007-04-09 12:21:38.411548000 +0100 Modify: 1984-12-12 10:15:00.000000000 +0000 Change: 2007-04-09 12:24:00.395254900 +0100 touch Bellagio-Fountain.jpg -a -t 198812121015.00 gives: File: `Bellagio-Fountain.jpg' Size: 370206 Blocks: 728 IO Block: 16384 regular file Device: 10h/16d Inode: 79777 Links: 1 Access: (3767/-rwxrwSrwt) Uid: ( 0/ root) Gid: ( 0/ root) Access: 1988-12-12 10:15:00.000000000 +0000 Modify: 1984-12-12 10:15:00.000000000 +0000 Change: 2007-04-09 12:26:50.344939800 +0100 with null files, this works just file and the dates are preserved. My install of a vmware win 2003 server was not productive, suffice to say even with an unpatched server this behaviour is consistent. However, i installed debian 3.1 as a virtual machine and copied the files and it works! dates and times are preserved. This is just weird now. G
(In reply to comment #9) > (In reply to comment #8) > > Sounds like an issue with the remote end if one CIFS share works fine and > > another doesn't. Can you experiment modifying the mtime/atimes of files on both > > mounts using the -a and -m options to touch? > > > OK, using the following on the remote (windows 2003 server) give the following > > touch Bellagio-Fountain.jpg -m -t 198412121015.00 > > stat Bellagio-Fountain.jpg > File: `Bellagio-Fountain.jpg' > Size: 370206 Blocks: 728 IO Block: 16384 regular file > Device: 10h/16d Inode: 79777 Links: 1 > Access: (3767/-rwxrwSrwt) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2007-04-09 12:21:38.411548000 +0100 > Modify: 1984-12-12 10:15:00.000000000 +0000 > Change: 2007-04-09 12:24:00.395254900 +0100 > > touch Bellagio-Fountain.jpg -a -t 198812121015.00 > > gives: > File: `Bellagio-Fountain.jpg' > Size: 370206 Blocks: 728 IO Block: 16384 regular file > Device: 10h/16d Inode: 79777 Links: 1 > Access: (3767/-rwxrwSrwt) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 1988-12-12 10:15:00.000000000 +0000 > Modify: 1984-12-12 10:15:00.000000000 +0000 > Change: 2007-04-09 12:26:50.344939800 +0100 > > with null files, this works just file and the dates are preserved. > > My install of a vmware win 2003 server was not productive, suffice to say even > with an unpatched server this behaviour is consistent. > > However, i installed debian 3.1 as a virtual machine and copied the files and > it works! dates and times are preserved. > > This is just weird now. > G > Found this on the kernel mailing list; http://bugzilla.kernel.org/show_bug.cgi?id=6127 Is it relevant?
No, unless you are using NFS
Created attachment 118309 [details] strace of a copy of a text file This was done on a 2.6.20-gentoo-r6 based machine using cifs as the filesystem. the windows box is a fully patched XP.
Created attachment 118311 [details] strace of a copy of a null file (same as the above)
(In reply to comment #13) > Created an attachment (id=118311) [edit] > strace of a copy of a null file > > (same as the above) > Hi, Sorry, I don't understand how to read a strace output. Does this verify the behaviour I am seeing on my system? Thanks
(In reply to comment #14) > (In reply to comment #13) > > Created an attachment (id=118311) [edit] > > strace of a copy of a null file > > > > (same as the above) > > > > Hi, > > Sorry, I don't understand how to read a strace output. > Does this verify the behaviour I am seeing on my system? > > Thanks > I forgot to mention that if i copy the files over ssh with -p flag, then the files do preserve their datestamps.
(In reply to comment #14) > (In reply to comment #13) > > Created an attachment (id=118311) [edit] > > strace of a copy of a null file > > > > (same as the above) > > > > Hi, > > Sorry, I don't understand how to read a strace output. > Does this verify the behaviour I am seeing on my system? > > Thanks > Yes.... it proves the bug exists.
Greg, please now move to filing a CIFS bug upstream at http://bugzilla.kernel.org. Keep the report simple to start with, e.g.: "Timestamps are not preserved when copying files larger than 0 bytes to a windows share using 'cp -pa' from recent coreutils". I'll then add the details. The bug you referenced earlier is actually somewhat relevant - that is exactly the same bug, but in NFS. Post the new bug URL here when done.
(In reply to comment #17) > Greg, please now move to filing a CIFS bug upstream at > http://bugzilla.kernel.org. Keep the report simple to start with, e.g.: > "Timestamps are not preserved when copying files larger than 0 bytes to a > windows share using 'cp -pa' from recent coreutils". I'll then add the details. > > The bug you referenced earlier is actually somewhat relevant - that is exactly > the same bug, but in NFS. > > Post the new bug URL here when done. Thanks Daniel, Done. http://bugzilla.kernel.org/show_bug.cgi?id=8437 >
