On Wed 29 Apr 2020 at 15:07:52 (-0400), Alberto Sentieri wrote:
When I tried strace with /bin/cp -pi I can see on both commands
something like this:
utimensat(4, NULL, [{tv_sec=1588174263, tv_nsec=908624390} /*
2020-04-29T11:31:03.908624390-0400 */, {tv_sec=1486350336,
tv_nsec=481422339} /* 2017-02-05T22:05:36.481422339-0500 */], 0) = 0
The utimensat is exactly the same for both cp -pi to a ext4 file
system or to a smb filesystem. So, cp seems to be working as expected.
Probably the same is true to /bin/mv.
There's no possibility, is there, that you're reading the file status
time rather than the file modification time? cp -ip/mv will update the
former though not the latter. All three times will be set by touch in
the absence of any options (c and m).
I'm not familiar with cifs/smb protocols and filesystems.
-----------------------------------------------------------------
Exactly the same behavior for /bin/cp and /bin/mv. I do not have any other cp or mv in my path.
$ sha1sum /bin/cp /bin/mv
220687a082fb9d0dbb48e9a2b1093cbb4e9de55a /bin/cp
46e71d67df7eb1c41f8f8c9039f401e242cce94a /bin/mv
On Wed, Apr 29, 2020 at 12:22:41PM -0400, Alberto Sentieri wrote:
cp and mv are not preserving the file timestamps when copying from a ext4
file system to a smb file system.
I am running cp and mv on:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
SMB is running on:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.12 (stretch)
Release: 9.12
Codename: stretch
I am using "cp -pi" to copy the files and "mv -i" to move them.
If I run cp or mv on a Debian stretch, time stamps will be correct on the
SMB file system.
Buster gnome3 file manager will copy or move the files without problems, I
mean, they will preserve time stamps.
This started happening since I upgraded my workstation to buster, so the
problem seems to be in buster. I am mounting the file system on buster with
the following line added to fstab, which, by the way, is the same I was
using when my workstation was running stretch:
//192.168.1.2/alberto /mnt/u1/rw cifs
credentials=/root/pass/alberto.pass,uid=alberto,gid=alberto,rw 0 0
Does anyone knows which package is causing this behavior?
First, do you see the same behavior if you use /bin/cp and /bin/mv
instead of simply cp and mv?
Cheers,
David.