I tried setfattr as you suggested with "user" and without "user". Both
failed with "Operation not supported" and none of them changed the
timestamp.
On 4/29/20 5:31 PM, Thomas Schmitt wrote:
Hi,
assumed that the success of "touch" indicates that utimensat(2) works
fine, i would pick the failed fsetxattr(2) as next suspect.
Does this set the timestamps despite failing ?
setfattr -n user.test_name -v test_value /mnt/u1/rw/receipt/u1.crontab
(I expect an "Operation not supported" error as in strace.
If it succeeds against our will, try -n "test_name", without prefix
"user.".)
Alberto Sentieri wrote:
So, the cp behavior on debian stretch and buster seems to be the same.
But the implementation of the system calls is not.
touch does the trick of dup2 and close, before calling utimensat.
Hm. To verify suchtheories you will have to create a C program which
uses the traced system calls and by which you can test variations.
Quite interesting would be to inquire the file timestamps immediately
after utimensat() in order to learn whether it gets into effect at
least for a short time.
Have a nice day :)
Thomas