I run tcpdump while running my simple program on both stretch and
buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while on
buster it uses SMB2 (version 2 or 3).
So, the problem can be solved by adding vers=1.0 to mount.cifs options.
Any version from 2.0 and above will incur in the same utimensat error. I
set vers to 1.0 and it worked properly.
While using SMB2, I can also see FILE_INFO/SMB2_FILE_BASIC_INFO on
buster as a result of utimensat, so something is being sent to the samba
server.
The question to be answered now is if this is a problem on buster side,
or or on samba stretch side. The later has all updates.
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