Comment 40 for bug 2007055

I kept digging into my specific issue, and now have to add a 4th dimension to the matrix of variables to consider that can affect modtime preservation: Samba configuration values. Here are the details.

For my issue, modtimes are not preserved on Synology devices due to the Synology's default SMB Advanced Setting in the "Others" section of its UI, "Synchronize data to drive immediately upon SMB client request"

This preference controls the smb "strict sync" configuration value. It was changed from False to True 6 years ago in Samba 4.7.0: https://gitlab.com/samba-team/samba/-/commit/ed483d8e570700a303e11bc03d6250cd0ae4aaed

Synology devices still default this value to False though. Unfortunately, the False value causes a Samba bugfix that helped with correct modtimes to not work. This bugfix is here: https://gitlab.com/samba-team/samba/-/merge_requests/1210/diffs?commit_id=945158c7652bd0580828fb620afc722bc8a05967 .

Unfortunately that bugfix does not work when strict sync is disabled, because smbd_smb2_flush_send checks lp_strict_sync and returns early instead of setting the smbd_smb2_flush_done callback to run; smbd_smb2_flush_done is where one of the modtime-related fixes was made.

(I've double validated that it is this setting that makes the difference. Setting it to True on the Synology device causes modtimes to be preserved. Setting it to False on an Ubuntu VM that was preserving modtimes causes it to stop.)

I passed this info on to Synology in case they are interested in changing the default value to match what Samba defaults to. I'll also mention the issue with the Samba bugfix for modtimes to the Samba project in case they are interested.