[Pkg-samba-maint] Bug#959211: utimensat system call no working properly on SMB shares

[Michael Tokarev]

On Thu, 30 Apr 2020 16:59:56 -0400 Alberto Sentieri <22t at tripolho.com> wrote:
> Package: samba
> Version: 4.5.16
> 
> The system call utimensat is failing when the protocol version is 2.0 or 
> upper is selected.
> 
> The package samba version 2:4.5.16+dfsg-1+deb9u2 is the last one 
> available for Debian stretch. Its interaction with Debian buster using 
> cifs-utils version 2:6.8-2 is causing the particular system call to 
> fail. In my case, the samba server is running under debian stretch, 
> while the workstation is running debian buster. A simple program like 
> </bin/cp -p> of </bin/mv> from a ext4 file system to the SMB file system 
> will store the incorrect time stamp on the samba server.
> 
> /bin/cp program executes some code like this, before finishing:
> 
> write (fd, buffer, length);
> utimensat (fd, NULL, timestamps, 0);
> close (fd);
> 
> I create a C program which will execute this sequence of statements. 
> Curiously the time stamp is correct for a small amount of time, and then 
> it switches to the current time. The program, which I called x2, will be 
> run by the following batch script:
> 
> #!/bin/bash
> NAME='/samba_share/test2.txt'
> rm -f "${NAME}"
> ls -ls "${NAME}"
> ./x2 "${NAME}"
> ls -ls "${NAME}"
> sleep 1
> ls -ls "${NAME}"
> 
> The result of running the script is:
> 
> $ ./script.sh
> ls: cannot access '/samba_share/test2.txt': No such file or directory
> 0 -rwxr-xr-x 1 u1 u1 10 Feb  5  2017 /samba_share/test2.txt
> 1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 16:33 /samba_share/test2.txt
> 
> As one can see, the file time stamp is correct just after x2 finishes, 
> and it become incorrect one second later. If, while mounting the share 
> with mount.cifs, I specify -o vers=1.0, then the problem does not 
> happen, I mean, the time stamp will be the same (Feb 5 2017) just after 
> x2 ends and 1 second after its end.
> 
> The program x2 uses the same sequence of commands that /bin/cp -p or 
> /bin/mv uses. Here is its source code:

Hi!

This is an interesting bug report.

The problem here seems to be some buffering (in samba?). And this your
test script above shows it nicely.

  open
  write...   - this is buffered
  utimensat  - the file timestamp is set, but the file is empty
  close      - the file's still empty!
  ... some time later ...
  write the buffer behind the scenes..
  obviously the write resets the timestamp

I don't know where this buffering is done. It would be interesting
to find out, -- apparently this is something which should not happen
at least this way, - whomever does the buffering must flush its
buffers before changing file timestamps.  And the fact that the
write is still not happened after close() is also at least questionable
behavior: how do we know about the possible write errors?  May be
you enabled some extra write cache? (which still should not have
this effect on setting the timestamp).

The fact that the older protocol works means that for *that* set of
available on-wire commands, things are done correctly, but for some
new command available in a more recent protocol, this is not done.

Can you check if this is still the prob with samba 4.16?

This should definitely be reported upstream.

Thank you for the excellent bug report!

/mjt