Re: unexpected behavior of cp and mv
Thanks.
By any chance is there a cifs specialist watching this thread?
Apparently the timestamp is initially correct but it changes after a
while. Does anyone knows why? Is there a worker finishing the file copy,
which could be creating this effect?
I wrote the following script to repeat my tests:
#!/bin/bash
rm -f /mnt/u1/rw/receipt/u1.crontab
/bin/stat /mnt/u1/rw/receipt/u1.crontab
/bin/cp -pi /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/
ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
/bin/stat /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
sleep 1
ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
/bin/stat /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
The result is this:
$ ./do_it.sh
/bin/stat: cannot stat '/mnt/u1/rw/receipt/u1.crontab': No such file or
directory
4 -rw-r--r-- 1 u1 u1 54 Feb 5 2017 /mnt/1g/home/u1/data/u1.crontab
0 -rwxr-xr-x 1 u1 u1 54 Feb 5 2017 /mnt/u1/rw/receipt/u1.crontab
File: /mnt/1g/home/u1/data/u1.crontab
Size: 54 Blocks: 8 IO Block: 4096 regular file
Device: 831h/2097d Inode: 58721601 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ u1) Gid: ( 1000/ u1)
Access: 2020-04-29 11:31:03.908624390 -0400
Modify: 2017-02-05 22:05:36.481422339 -0500
Change: 2017-02-05 22:05:36.581420492 -0500
Birth: -
File: /mnt/u1/rw/receipt/u1.crontab
Size: 54 Blocks: 0 IO Block: 16384 regular file
Device: 2ch/44d Inode: 75374568 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 1000/ u1) Gid: ( 1000/ u1)
Access: 2020-04-29 11:31:03.908624300 -0400
Modify: 2017-02-05 22:05:36.481422300 -0500
Change: 2020-04-30 10:04:07.613793700 -0400
Birth: -
4 -rw-r--r-- 1 u1 u1 54 Feb 5 2017 /mnt/1g/home/u1/data/u1.crontab
1024 -rwxr-xr-x 1 u1 u1 54 Apr 30 10:04 /mnt/u1/rw/receipt/u1.crontab
File: /mnt/1g/home/u1/data/u1.crontab
Size: 54 Blocks: 8 IO Block: 4096 regular file
Device: 831h/2097d Inode: 58721601 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ u1) Gid: ( 1000/ u1)
Access: 2020-04-29 11:31:03.908624390 -0400
Modify: 2017-02-05 22:05:36.481422339 -0500
Change: 2017-02-05 22:05:36.581420492 -0500
Birth: -
File: /mnt/u1/rw/receipt/u1.crontab
Size: 54 Blocks: 2048 IO Block: 16384 regular file
Device: 2ch/44d Inode: 75374568 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 1000/ u1) Gid: ( 1000/ u1)
Access: 2020-04-29 11:31:03.908624300 -0400
Modify: 2020-04-30 10:04:07.611931500 -0400
Change: 2020-04-30 10:04:07.611931500 -0400
Birth: -
On 4/30/20 6:39 AM, Thomas Schmitt wrote:
Hi,
Alberto Sentieri wrote:
I tried setfattr as you suggested with "user" and without "user". Both
failed with "Operation not supported" and none of them changed the
timestamp.
This only leaves the idea to mimick the strace of cp -p in an own
C program to see whether utimensat() has the desired effect and
whether following calls spoil it.
Maybe it is necessary to really create a new file and to write
some realistic amount of data to it in order to set up the conditions
for the problem.
The code of cp.c and copy.c in
https://sources.debian.org/src/coreutils/8.30-3/src/
looks not overly self-contained. So it might be difficult to get a
debuggable version of cp, if not Debian package development magic can
produce it.
Have a nice day :)
Thomas
Reply to: