NTFS to ext4 not copying modified/created dates

[Herondas]

On Linux Mint 22 are mounted NTFS disks.
Trying to freefilesync copy folders from NTFS to ext4.
Freefilesync shows NTFS file dates correctly but after copy test all the files on ext4 shows date/time modified to when the copy was run and date/time created as unknown.

Is there any way to get the dates to carry over to ext4?

[bernd.g.]

Hi had more or less same issue - using FreeFileSync Version: 14.8 • x86-64 • 22.02.2026

On Linux Zorin OS 18 copy from ext4 to NAS Synology File properties not copied according source.
date/time modified & created is date/time of copy run-

Copy from NTFS to NAS Synology same issue.

[Zenju]

viewtopic.php?t=12835#p49832

[bernd.g.]

Hello Zenju,
I now have a reproducible result with strace.

Environment:
Zorin OS 18
FreeFileSync 14.8
Target NAS: Synology DS225+
CIFS mount used for most jobs: /media/nas/...

Example job:
Source: /home/bg/.thunderbird/bg.default-release
Target: /media/nas/home/bg_laptop/BG-Thunderbird/bg.default-release

Findings
cp -p to the same CIFS target preserves the modification time correctly.
A very small FreeFileSync test job also preserved the modification time correctly.
However, a real FreeFileSync job (Thunderbird profile) does not preserve the modification time on the CIFS path.
The same Thunderbird job does preserve the modification time correctly when using a GVFS SMB path instead of the CIFS mount.

Example working path:
/run/user/1000/gvfs/smb-share:server=synologyds225.local,share=homes/BG/bg_laptop/BG-Thunderbird/bg.default-release

Important strace result

For example for prefs.js, FreeFileSync performs the following steps:

unlink target file
create new file
write file content
call utimensat() with the source modification time

Relevant trace excerpt:

unlink("/media/nas/home/bg_laptop/BG-Thunderbird/bg.default-release/prefs.js") = 0
stat("/home/bg/.thunderbird/bg.default-release/prefs.js", {st_mode=S_IFREG|0775, st_size=37787, ...}) = 0
openat(AT_FDCWD, "/home/bg/.thunderbird/bg.default-release/prefs.js", O_RDONLY|O_CLOEXEC) = 17

openat(AT_FDCWD, "/media/nas/home/bg_laptop/BG-Thunderbird/bg.default-release/prefs.js",
O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0775) = 18

write(18, "...", 37787) = 37787

utimensat(18, NULL,
[{tv_sec=1773668206, tv_nsec=0},
{tv_sec=1773668083, tv_nsec=756575856}], 0) = 0

close(18) = 0

utimensat(AT_FDCWD,
"/media/nas/home/bg_laptop/BG-Thunderbird/bg.default-release/prefs.js",
[{tv_sec=1773668206, tv_nsec=0},
{tv_sec=1773668083, tv_nsec=756575856}], 0) = 0

Both utimensat() calls return success (= 0).

But immediately after the sync

stat -c '%n | %y' \
/home/bg/.thunderbird/bg.default-release/prefs.js \
/media/nas/home/bg_laptop/BG-Thunderbird/bg.default-release/prefs.js

Result:
/home/bg/.thunderbird/bg.default-release/prefs.js
2026-03-16 14:34:43.756575856 +0100
/media/nas/home/bg_laptop/BG-Thunderbird/bg.default-release/prefs.js
2026-03-16 14:36:47.950885600 +0100

So the target file ends up with the write time instead of the source mtime, even though utimensat() reports success.

Workaround
As a temporary workaround I switched this job to the GVFS SMB path instead of the CIFS mount.
With the GVFS SMB path the modification time is preserved correctly and FreeFileSync comparisons work as expected.

Example working target path:
/run/user/1000/gvfs/smb-share:server=synologyds225.local,share=homes/BG/bg_laptop/BG-Thunderbird/b