Re: unexpected behavior of cp and mv
Just to document what I've seen so far:
These are some straces which may help finding the problem:
1) cp -p from ext4 to smb, debian buster, which failed:
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
fgetxattr(3, "system.posix_acl_access", 0x7ffd302bd820, 132) = -1
ENODATA (No data available)
fstat(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
fsetxattr(4, "system.posix_acl_access",
"\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377
\0\4\0\377\377\377\377", 28, 0) = -1 EOPNOTSUPP (Operation not supported)
fchmod(4, 0100644) = 0
close(4) = 0
close(3) = 0
munmap(0x7fda0caa2000, 139264) = 0
lseek(0, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
close(0) = 0
close(1) = 0
close(2) = 0
exit_group(0) = ?
+++ exited with 0 +++
2) cp -p from ext4 to ext4, debian buster, which worked correctly:
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
fgetxattr(3, "system.posix_acl_access", 0x7fffea95d4d0, 132) = -1
ENODATA (No data available)
fstat(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
fsetxattr(4, "system.posix_acl_access",
"\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377
\0\4\0\377\377\377\377", 28, 0) = 0
close(4) = 0
close(3) = 0
munmap(0x7f13495c9000, 139264) = 0
lseek(0, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
close(0) = 0
close(1) = 0
close(2) = 0
exit_group(0) = ?
3) touch smb file, debian buster (command touch -t 202001011700
u1.crontab), which works correctly:
openat(AT_FDCWD, "u1.crontab", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK,
0666) = 3
dup2(3, 0) = 0
close(3) = 0
utimensat(0, NULL, [{tv_sec=1577916000, tv_nsec=0} /*
2020-01-01T17:00:00-0500 */, {tv_sec=1577916000, tv_nsec=0} /*
2020-01-01T17:00:00-0500 */], 0) = 0
close(0) = 0
close(1) = 0
close(2) = 0
exit_group(0) = ?
4) cp -p from ext4 to smb on debian stretch, which works correctly:
utimensat(4, NULL, [{tv_sec=1588174263, tv_nsec=908624390},
{tv_sec=1486350336, tv_nsec=481422339}], 0) = 0
fgetxattr(3, "system.posix_acl_access", 0x7ffdd4465000, 132) = -1
ENODATA (No data available)
fstat(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
fsetxattr(4, "system.posix_acl_access",
"\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377
\0\4\0\377\377\377\377", 28, 0) = -1 EOPNOTSUPP (Operation not supported)
fchmod(4, 0100644) = 0
close(4) = 0
close(3) = 0
munmap(0x7f8ab2aaf000, 139264) = 0
lseek(0, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
close(0) = 0
close(1) = 0
close(2) = 0
exit_group(0) = ?
So, the cp behavior on debian stretch and buster seems to be the same.
touch does the trick of dup2 and close, before calling utimensat.
Alberto
On 4/29/20 4:13 PM, Thomas Schmitt wrote:
Hi,
Alberto Sentieri wrote:
It is clear
there that -p has no effect on that particular case of smb destinations. A
similar problem is happening with mv.
Maybe its not the file copying operation but the subsequent adjustment
of the timestamps.
Did you already try whether you can change timestamps on SMB by e.g.
touch(1) ?
Have a nice day :)
Thomas
Reply to: