samba - Aug 2025 - delayed mtime updates: configurable?

...adding linux-cifs to the loop...

On 8/1/25 11:35 AM, hede via samba wrote:
> On Sun, 27 Jul 2025 18:45:17 +0200 hede via samba
> <samba at lists.samba.org> wrote:
> 
>> Hi,
>> 
>> SMB 2.1 and up seems to have a delayed mtime update. If writing to
>> a file on the client, the modification time (mtime) for this file
>> gets updated some time after closing. Typically ~1 second after
>> closing the file.
> 
> It's a feature, not a bug. Somehow.
> 
> It's the deferred close feature implementation within cifs.ko which
> delays the mtime update. With "closetimeo=0" the problem is gone.
no idea what the client is doing here, but from a server perspective, 
with current Samba, the write will *immediately* update the mtime on 
disk and report this updated value whenever it is queried. When the 
handle is closed, the server doesn't update the mtime.

A network trace will tell you the truth about what's going on.

Cheers!
-slow

-- 
SerNet Samba Team Lead https://sernet.de/
Samba Team Member      https://samba.org/
Samba Support and Dev  https://samba.plus/services/
SAMBA+ packages        https://samba.plus/products/samba
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20250801/24ce3313/OpenPGP_signature.sig>

On Fri, 1 Aug 2025 12:18:43 +0200 Ralph Boehme <slow at samba.org> wrote:
> no idea what the client is doing here, but from a server perspective, 
> with current Samba, the write will *immediately* update the mtime on 
> disk and report this updated value whenever it is queried. When the 
> handle is closed, the server doesn't update the mtime.
According to a net-trace it seems the client updates mtime several times for a
single write event. The last seems done _after_ flushing and before closing the
file, so the last mtime change will get flushed not until the deferred close
finishes. (i.e. closetimeo seconds after the final write and after closing the
file on client-side)

If I comment out the following:

##### in fs/smb/client/file.c in function cifs_close() #####

/*
if (test_and_clear_bit(CIFS_INO_MODIFIED_ATTR, &cinode->flags)) {
        inode->i_ctime = inode->i_mtime = current_time(inode);
}
*/

##### 

... then I do not have problems with vim on client side. 
(my initial problem was that vim complains for a remotely changed file after
consecutive writes)

Still, on server side, even then the mtime gets changed not before the final
(deferred) close operation has finished.

Btw: Even with this functionality in affect, i.e. not commented out, the mtime
update is deferred until the real closing.
So instead of changing ctime&mtime to current_time() here, maybe some kind
of a "flush-command" would be helpful.

-

Additionally some different thing:

##### in fs/smb/client/file.c in function cifs_readpage_worker()

/* we do not want atime to be less than mtime, it broke some apps */
file_inode(file)->i_atime = current_time(file_inode(file));
if (timespec64_compare(&(file_inode(file)->i_atime),
&(file_inode(file)->i_mtime)))
        file_inode(file)->i_atime = file_inode(file)->i_mtime;
else
        file_inode(file)->i_atime = current_time(file_inode(file));

#####

... is it intended to call the same function twice for the "else"
case?
And btw.: the same comment and functionality seems to be already in
cifs_fattr_to_inode() in fs/smb/client/inode.c

(I'm not a software developer so please apologise if I do have dumb ideas or
questions.)

I tested this with linux 6.1 / cifs 2.40 (Debian Stable) and linux 6.15 / cifs
2.54 (Arch Linux), not with the current master branch.

hede