Copying does not preserve timestamp anymore und Linux

[abruenin]

This is a new issue, I don't know if this came with a FFS or OS update.
During a sync, when files are copied to a mounted SMB drive, the destination files do net get the date of the source files, but the actual time stamp.
So when I compare both sides the next time, all these files are marked as different, because on the destination side all have a newer date.
How can I get the old behavior back?

[Plerry]

I can't help you with not retaining time stamps in your Linux setup.

However, you should be able to prevent files are detected as different and copied over and over again by
1) Checkmarking "Use database file to detect changes" in your synchronization settings (F8).
This assumes both sides involved in your sync have stable cross-sessions file-IDs.
OR
2) Defining a Custom sync variant in your synchronization settings (F8), matching your needs.

[xCSxXenon]

This type of issue has always been on the host side. Reboot whatever is hosting the SMB share(s) and make sure it is updated

[abruenin]

Double checked this with file system copy, this seems independent from the destination. I tried with Synology, RPi with LibreElec and GMX, all via SMB. When I do a simple cp, then the datetime in the destination is the actual datetime.
But with the -preservetimestamp option, the datetime of the source file is used. Can FreeFileSync be configured to copy with preservetimestamp?

[Zenju]

FreeFileSync closely models "cp -p", so there is no reason why the timestamp should not be copied. It's possible that the latest SMB update introduced bugs that would cause "utimensat" to fail silently (which is what FFS tries first). This could be checked via "strace": https://freefilesync.org/faq.php#trace

[abruenin]

OK, took me a while, did an strace while syncing one file that had the actual time, not the source time after syncing. Is this any helpfull?

cat ffs-strace.log
execve("/home/arne/.local/bin/freefilesync", ["freefilesync"], 0x7fff0d5049b0 /* 86 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x60abb8) = 0
set_tid_address(0x60acf0) = 23256
brk(NULL) = 0x1886c000
brk(0x1886e000) = 0x1886e000
mmap(0x1886c000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x1886c000
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f233b01b000
readlink("/proc/self/exe", "/home/arne/FreeFileSync/FreeFile"..., 4096) = 36
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f233b01a000
munmap(0x7f233b01b000, 16384) = 0
pipe2([3, 4], O_CLOEXEC) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1 RT_2], [], 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], ~[KILL STOP RTMIN RT_1 RT_2], 8) = 0
fork() = 23257
rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1 RT_2], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(4) = 0
read(3, "\n(FreeFileSync_x86_64:23257): IB"..., 16384) = 115
writev(2, [{iov_base="", iov_len=0}, {iov_base="\n(FreeFileSync_x86_64:23257): IB"..., iov_len=115}], 2
(FreeFileSync_x86_64:23257): IBUS-WARNING **: 17:10:17.515: Unable to connect to ibus: The given address is empty
) = 115
read(3, 0x7ffd91bfe96c, 16384) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
read(3, "", 16384) = 0
wait4(23257, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 23257
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=23257, si_uid=1000, si_status=0, si_utime=1297 /* 12.97 s */, si_stime=336 /* 3.36 s */} ---
close(3) = 0
munmap(0x7f233b01a000, 4096) = 0
exit_group(0) = ?
+++ exited with 0 +++

[Lantignon]

I have the same issue with a similar setup (syncing from a laptop to a Synology NAS mounted as a cifs share on a raspberry Pi via SFTP) but I found a solution. Downgrading the linux kernel from 6.12.62 to 6.12.47 fixed the issue.
There have been quite a few commits around cifs between these two releases, like this one which seems to be about setting the last access and modification time.
smb: client: fix missing timestamp updates after utime(2)

EDIT: so the problem isn't with FreeFileSync but seems to be the cifs module in the linux kernel

[abruenin]

Hey, thanks for your help. Just checked Manjaro settings manager, running on 6.18.4-1 I cannot switch to an older 6.12 Kernel than 6.12.64. But good to know, that this is a Linux kernel issue. Will try 6.19rc or go back to 6.6 LTS.

[Lantignon]

You could try 6.17. I'm running 6.12 which is a LTS so those patches were backported but they were picked from the 6.18 tree so 6.17 should work.

[abruenin]

OK, just tried 6.19rc, problem still persist.

[abruenin]

Downgrading the linux kernel from 6.12.62 to 6.12.47 fixed the issue.

OK, tried 6.12.64-1 LTS an problem is also in this kernel as you wrote. So I will go with the latest RC kernels and wait for this issue to be fixed.

[abruenin]

Double checked with OpenSuse Tumbleweed, which has also the same problem with Kernel 6.18
And this only occurs only from local to cifs. Cifs to local works as expected.

[Zenju]

OK, took me a while, did an strace while syncing one file that had the actual time, not the source time after syncing.

So this timestamp issue is not 100% reproducible? Is the same flaky behavior also seen when you copy manually to the server, e.g. via "cp"?

The strace you sent seems to not contain any file copy data, but is showing the launcher. You would need to strace <ffs install dir>/Bin/FreeFileSync_x86_64 directly. Then it will be possible to compare this result to "cp". But this only makes sense if "cp" is in fact reliably copying file times to SMB.

[Zenju]

Bonus: here's a test version that is using slightly more conformant open flags which should make FFS behavior identical to "cp": https://www.mediafire.com/file/reoh05nwpcpp0vx/FreeFileSync_14.8_beta_Linux_x86_64.tar.gz

[Lantignon]

But this only makes sense if "cp" is in fact reliably copying file times to SMB.

In my experience, even just copying to a SMB share with cp -p does'nt preserve the timestamps on the latest kernel. Haven't checked in a while but will do when able.

[abruenin]

Bonus: here's a test version that is using slightly more conformant open flags which should make FFS behavior identical to "cp": https://www.mediafire.com/file/reoh05nwpcpp0vx/FreeFileSync_14.8_beta_Linux_x86_64.tar.gz

Cool, many thanks. Will try it out this afternoon

[abruenin]

in my experience, even just copying to a SMB share with cp -p does'nt preserve the timestamps on the latest kernel. Haven't checked in a while but will do when able.

On my systems, cp -p does preserve the timestamps, whereas cp does not (which it did in the past). So maybe they have just changed the default? But I will do some more testing in the evening.

[Zenju]

Just to clarify: when I said "behavior identical to "cp"", I obviously meant
cp -p

[abruenin]

Thanks for the beta, unfortunately it seems to get worse in the Linux kernel. On my system, cp -p now also does not preserve the timestamp.

~/Data/Users/Davis> uname -a
Linux predator 6.19.0-rc7-1-MANJARO #1 SMP PREEMPT_DYNAMIC Mon, 26 Jan 2026 02:07:48 +0000 x86_64 GNU/Linux
~/Data/Users/Davis> ll Mittagessen.odt
-rwxr-xr-x 1 arne arne 10426 4. Feb 20:22 Mittagessen.odt
~/Data/Users/Davis> cp -p Mittagessen.odt /home/arne/net/users/Davis
cp: overwrite '/home/arne/net/users/Davis/Mittagessen.odt'? y
~/Data/Users/Davis> ls -l /home/arne/net/users/Davis/Mittagessen.odt
-rwxrwxrwx 1 1001 1001 10426 5. Feb 20:21 /home/arne/net/users/Davis/Mittagessen.odt

I have tried the FFS beta and it behaves excactly the same. Seems we need to wait for this to be fixed in Linux first.

[abruenin]

Just a quick update: I did a fresh Manjaro installation on a new laptop and synced from local disc to Ionos Hidrive via webdav and here, the timestamps are set as expected.

[abruenin]

But when syncing with my Synology via WebDav, the problem still persists. So it looks like a server side issue

[abruenin]

OK, knowing that this is only an issue with WebDAV and only with some servers, like my Synology DiskStation, I chagend the protocol for these connections to ftp and everything is fine for me.

[freefant]

I have part of the problem:
When Syncing to my Veracrypt-Container still created directories get the actual timestamp.

Actually used distro is a Tuxedo OS(ubuntu-based), synchronized files are on NTFS-filesystems

I see an improval on syncing files with Donation Version 14.9 :
Timestamps of files are kept (used it only with Windows version because of this problem.)