Re: unexpected behavior of cp and mv

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

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