1 second, 3 seconds or 10 minutes have the same result.
About the 1024 1K-blocks, if one checks the file size on the samba
server using the same <ls -ls> command, the return will be:
4 -rwxrw-r-- 1 root cifsusers 10 Feb 5 2017 test2.txt
So, it is using only 4Kbytes on the server. I have no idea why smb
interface always reports 1Mbyte. By the way, I have seen this behavior
for many years. stat (on the workstation) also reports the same (2048
512-byte blocks).
I will do the tests you suggested later. I am also thinking about trying
a flush before utimensat. None of this, however, happens in cp.
It may not be utimensat. Between the kernel and the smb, there is a cifs
package (the driver) which could be doing it wrong. Both the kernel and
cifs package are different between the two workstations.
Thanks,
Alberto
On 4/30/20 1:32 PM, Thomas Schmitt wrote:
Hi,
Alberto Sentieri wrote:
ls -ls "${NAME}"
Note that the /mnt/u1/rw/receipt is a SMB folder. I got this result:
1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 12:20 /mnt/u1/rw/receipt/test2.txt
[...]
I run the same binary and script on my debian stretch workstation, and got
4 -rwxr-xr-x 1 u1 u1 10 Feb 5 2017 /mnt/u1/rw/receipt/test2.txt
It is quite remarkable that the SMB file is reported to use 1024 blocks
for storing 10 bytes.
-------------------------------------------------------------------------
I am still not convinced that SYS_utimensat is to blame.
What do you get if you sleep for 3 seconds before performing it ?
If still the file timestamp changes with that sleep:
What happens if you close the fd without calling utimensat and
re-open the file for applying utimensat only then ?
(What if you let sleep between between close and re-open ?)
Have a nice day :)
Thomas