File "modified" date/time changed

[CCoolname]

Hi everyone,
I have also used FreeFileSync for many years with very much pleasure. However, since one of the later versions I experience the same issue as described above. The file modification date gets set to the current time instead of just copying it from the source location. This happens often on network drives, but also on my usb portable drive. I am using Windows 11 and FFS 13.6 (Donation Edition). This is a very important issue for me, as now FFS is not reliable anymore in this, limiting the usefullness of it a lot (I can now only use it with the file size compare option only, but that is not the idea of course). Pls help.

[xCSxXenon]

Hi everyone,
I have also used FreeFileSync for many years with very much pleasure. However, since one of the later versions I experience the same issue as described above. The file modification date gets set to the current time instead of just copying it from the source location. This happens often on network drives, but also on my usb portable drive. I am using Windows 11 and FFS 13.6 (Donation Edition). This is a very important issue for me, as now FFS is not reliable anymore in this, limiting the usefullness of it a lot (I can now only use it with the file size compare option only, but that is not the idea of course). Pls help.

As the rest of the thread AND other threads have shown, this is not a FFS issue or something that FFS can even remedy in most situations.

[moongate]

Hi CCoolname, xCSxXenon,

I noticed the problem after upgrading to 13.1 when syncing to smb shares from my Win 11 PCs.
For me it was fixed in the 13.2 beta and as such in the 13.2 final release.

I must admit I failed to pay close attention on the possibilty of a re-introduction of the issue.
You are ruling out FFS but maybe the same code found its way in a later release again :-)

I will resync later today and post again if I see that the issue is coming back for me with 13.6 with the rest of my setup being unchainged.

[CCoolname]

Hi both,

Thanks for your quick responses!
@xCSxXenon: I understand what you are saying. But...we have the situation that many of us are using Windows. And even if Windows has some issues: should we not try to aim having a tool that works with it in a correct way? Even if there are some non-perfect elements in Windows, we cannot do anything else then living with it, right? Maybe I was not perfectly clear, but: if I use windows explorer, the file copies perfectly, without any issues. But when FSS copies a file, the destination file modification date gets the date/time of moment of copying instead of the original date. (in both directions, so towards the usb drive and towards the local harddrive). I do not have this issue with any other tools I use, so there is something that FSS does that introduces this issue. Something that the other tools do not do. (and maybe FSS should not do either).
@moongate: thanks! That would indeed be interesting! Appreciated if you could try indeed.
thanks!

[moongate]

So, I completed my testing.
I am running 13.6 64Bit at the moment.
I copied a local file from 2023 on my Win 11 23H2 PC into a folder that has been setup for FFS.
The local copy did not change the modified date as expected.
The FFS rule is set to sync with my NAS via SMB share.
I performed the sync and the resulting file on my NAS still has the desired modify date from 2023.

I then downgraded to 13.1 and see that the modified date is changed to the time of the sync, which is not desired.

Once I update to 13.6 again, issue is gone and I get the desired results of synced file dates being equal to the original file dates on my PC.

[Teoma]

Hi everyone,
I'm happy to confirm moongate's findings. FFS works magically again!

There is one little important piece of information, which I'll get to in a moment. I'm using the following setup now:
- macOS Sonoma 14.5
- FreeFileSync 13.6 donation edition
- VeraCrypt 1.25.9

In our company we store finance and coworkers related information in a verycrypt container on a NAS (network attached storage). The files are also on the SSD harddrive of my Mac, without encryption. My colleague accesses the NAS from a windows PC, so we have the choose FAT or exFAT for the veracrypt container.

I ran 3 tests now with different file systems for the veracrypt container:
- mac OS extended: FFS does NOT change the modified date, as desired <- cannot be accessed by windows, though
- exFAT: FFS does NOT change the modified date, as desired <- our choice
- FAT: FFS changes the modified date, which is creates problems.

We don't need to use FAT for the veracrypt volume, so all is good on my side. :)

[mvcauter]

Hi everyone,
I experience the same issue than those mentioned above.

So I conducted extensive tests, and came to realise that this 'feature' (of changing the target timestamp) is there at least since FFS 11 (I could not test earlier version).
See below for the details. BTW I have also all the screenshots to demonstrate the results.
I can open a new thread if that helps, let me know.

Simple Mirroring Folder_A to Folder_B on same device/disk
##################################################
Note: this is avoid any SFTP, NAS, USB, RAID, etc...

Testing Environment:
-------------------------
- macOS Sonoma 14
- macOS BigSur 11
- FFS 13.7
- FFS 12.0
- FFS 11.29

Testing cases (on both macOS versions):
------------------------------------------------
1) Finder’s copy/paste : Both sides are identical
2) terminal command: cp -Rp ./source ./target : : Both sides are identical
3) FFS 11.29 : timestamp on 'new' target folder equals the sync. timestamp
4) FFS 12.0 : timestamp on 'new' target folder equals the sync. timestamp
5) FFS 13.7 : timestamp on 'new' target folder equals the sync. timestamp
Note: I tested many more versions but all gave the same results.

FFS GlobalSettings.xmlc as of FFS 12+):
-----------------------------------------------
<FailSafeFileCopy Enabled="true"/>
<CopyLockedFiles Enabled="false"/>
<CopyFilePermissions Enabled="false"/>
<FileTimeTolerance Seconds="2"/>
<RunWithBackgroundPriority Enabled="false"/>
<LockDirectoriesDuringSync Enabled="false"/>
<VerifyCopiedFiles Enabled="false"/>

FFS JOB Sync. Settings:
----------------------------
- Comparison: Select by file time & size
- Filter: defaults
- Synchronisation: Mirror; Delete & override = permanent

[CCoolname]

Hi all,
I too did some testing an figured out some very strange results. My testing:
Windows 11 (but 10 had same issues):
Folder 1: NTFS on internal drive of Windows 11 machine
Folder 2: NTFS on USB drive (same with shared network drive)

After some extensive testing I found out that the changing modified date/time issue is file dependent!! I found some files that persistently had the modification date changed to the date/time of syncing with FSS, irrespective of there location etc. And some other files (in same folders) never have the modification date changed!
What I did now as a test was, I opened a copy of a file that has this changing date/file issue with FSS. I made a small change with Word and saved it again. And afterwards, this new file does not have the changing mod date/file anymore! So now I have a folder with 2 almost identical docx files. And when I sync that folder to another NTFS drive/folder or network drive, I have one file of which the date/time is changed each time and another file of which the date/time is not changed!

Files are not corrupt or anything like that (and I have the issue with 1000-s of files) and I can just open both files with Word as mentioned. When I do the same copy-ing with Windows explorer, both date/file attributes stay as they should. It only goes wrong with FSS and with certain files, as explained above.
I also did the same testing with an external FAT32 drive, and there all goes well (no changes in date/time of either files). I also repeated the above several times with other types of files, with exactly the same above described results (so no specific single file issue or something like that). All the above is by the way valid for both directions.

Another thing I noticed: the files that get a changed date/file when copied with FSS also get a changed date/time when I rename them with explorer (while renaming the other files on exactly the same location does not result in changing the date/time when renaming). So not when copying or moving.

All very strange to me, but maybe the above helps to tackle the problem. From a distance, the issue might seem minor (who cares about details like modified date/time?). But in reality, it makes the whole FFS tool quite useless to me, as files keep on getting copied forward and backward due to this date/time change (where FSS itself looks at to detect changes).

[Zenju]

Perhaps these files have NTFS alternate data streams, which triggers your anti virus software that is ultimatively responsible for the failed modification time.
See: https://freefilesync.org/faq.php#different-after-sync

[mvcauter]

Hi Zenju,

Well on my testing devices (macOS Sonoma 14, macOS BigSur 11), see post of 5-jul, I don't have anti-virus running.

For what I could peak in the available source-code (https://github.com/hkneptune/FreeFileSync), in 'native.cpp', the function copyNewFolderForSameAfsType() calls copyDirectoryAttributes():
...
try
{
copyDirectoryAttributes(sourcePathNative, targetPathNative); //throw FileError
}
...
in 'file_access.cpp', it looks like the copyDirectoryAttributes() does not do much except checking for 'root path':
void zen::copyDirectoryAttributes(const Zstring& sourcePath, const Zstring& targetPath) //throw FileError
{
//do NOT copy attributes for volume root paths which return as: FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM | FILE_ATTRIBUTE_DIRECTORY
//viewtopic.php?t=5550
if (!getParentFolderPath(sourcePath)) //=> root path
return;
}
...
For sure I may have overlooked something, but in the end, 'mirror' jobs (on local devices) don't align folder timestamp (left to right).
Would you consider to improve this functionality ?
Thanks
Marc