Re: unexpected behavior of cp and mv

[Alberto Sentieri <22t@tripolho.com>]

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