samba - Jul 2025 - delayed mtime updates: configurable?

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.

This is reproducible[1] with shares provided via Samba and Windows, both mounted
on Linux via cifs kernel module. So I think this is NOT a bug but on purpose /
with intent / by design.


I simply wonder why this is the case and why this design decision was chosen.
And especially: is it possible to have the mtime-behaviour of SMB 2.0 with newer
SMB versions?


The problem is for applications which do rely on modification time of files, for
example vim. If writing to a file via ":w", then do further edits and
write a second time, vim complains: "WARNING: The file has been changed
since reading it!!!"

This does not happen if the SMB-filesystem is mounted with "ver=2.0".
And it is not related to caching, because the delay is mostly ~1 second even
with actimeo=0 or actimeo=2. So even "actimeo=0" does not help here.

This observation seems to be discussed already in the past and I'm pretty
sure the answer was already given, somewhere. But I didn't find it. At least
I do not see it. I didn't find a conclusion nor an explanation why this
happens. I didn't find any explanation why this design decisions were chosen
(i.e. what the probably good reasons are) and neither if there are any
configuration options to change this behaviour (obviously with braking to behave
like windows does). So if this is a dump question because there is already some
good explanation given, please tell me and please have my apologies.

I would be happy if someone has a good explanation or a solution to deal with
this (i.e. get rid of the errors with vim).

regards
hede



Here are more details (as I think a more experienced samba user or developer
will have an explanation or even a solution already at hand, I do not think more
details are needed - nevertheless I give some):

[1] I tried the following:

Several systems for the server side: 
Windows 11 2H24, Debian stable (Samba 4.17.12) and Debian trixie (Samba 4.22.3).
Default smb.conf provided with Debian for Samba hosts. 

Client side: CIFS/SMB3 module in Linux 6.15.6 (Arch Linux) and 6.1.140 (Debian
stable).
mount command for SMB3 / 3.1.1 tests: 
# mount -t smb3 -o uid=[username],username=[username] //[server]/[drive]
/mnt/tmp2
mount command for SMB2 tests:
# mount -t cifs -o vers=2.0,uid=[username],username=[username]
//[server]/[drive] /mnt/tmp2

I've watched the mtime changes with the following command on client side:
# LANG=C watch -n 0.1 "stat test.txt | grep Modif"

Then I edit a file, with several different methods:
# LANG=C vim test.txt
# nano test.txt
# echo "asd" >> test.txt
-> result: several updates of mtime, typically immediately and after ~1
second

If overwriting the whole file with "echo something > test.txt",
then the mtime gets only updated immediately. No further updates.

All systems do behave nearly the same, regardless if the server is Windows or
Samba and with newer or older linux clients. When writing a file on a SMB
filesystem mounted "vers=2.0" then the mtime timestamp gets updated
immediately with no further updates to the mtime timestamp.
With "vers=2.1" or any newer version the mtime timestamp gets updated
immediately and probably several subsequent updates do happen.

vim complains on SMB 2.1 and up with the following message for any subsequent
writes after the first one:
"WARNING: The file has been changed since reading it!!!"

When transferring files via "cp -a" to the SMB share, the mtime first
gets the current time and one second later this is updated to the (correct)
mtime of the source file.

This behaviour doesn't make any sense to me. 
Expected behaviour would be: the mtime of the file is immediatly the correct
one.

For vim I do have a workaround, to reload the file one second after the last
write:
set autoread
autocmd FileWritePost * call timer_start(1000, { tid ->
execute('checktime')})
autocmd BufWritePost * call timer_start(1000, { tid ->
execute('checktime')})

... yet the "issue" is on the filesystem side and this is only a (not
even fully reliable) workaround.

On 7/27/25 6:45 PM, hede via samba wrote:
> I would be happy if someone has a good explanation or a solution to
> deal with this (i.e. get rid of the errors with vim).
delayed write time updates have recently been removed from Samba as 
modern Windows versions also don't do delayed updates:

https://bugzilla.samba.org/show_bug.cgi?id=13594

iirc the next major version scheduled for release in September will ship 
with the above changes.

Not sure if the client does some magic on its own.

-- 
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/20250727/c8c81bca/OpenPGP_signature.sig>

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.

Yet, the deferred close itself is not the problem here. It's the deferred
mtime update which is of harm here, which (by effect) is prevented with
disabling deferred close.

So my "feature request" would be to immediately update the mtime on
close, even if deferring the close operation itself. But I do not know if that
is reasonable.

thanks
hede