File "modified" date/time changed

[varez]

I'm currently using FreeFileSync on ARM64 Mac.
Ever since version 13.0, synchronization copy seems to change the file "modified" date/time to the time of the sync. This means every time I perform a Mirror sync (file time and size) between two drives, files on the target drive is considered a newer copy than one in the source, even if no actual change is performed.

So long story short, all files synced prior to version 13.0 is considered unchanged and untouched. But anything after version 13.0 is overwritten over and over again. Is this an oversight, or is there a setting somewhere that I am missing?

[xCSxXenon]

Have you verified that reverting to a previous FFS version fixes this? This doesn't sound like a FFS issue and is typically cause by file system or other factors

[moongate]

Hello All,

I came here because I am facing the same issue on FreeFileSync 64- Bit 13.1 on Windows.

So far synced files would have the same timestamps as the source files.
This is true for:
- date created
- date modified
- last accessed


Today I noticed that the target files incorrectly receive the same date and time stamp for all three categories - which is the time the sync took place.

In my mind that is absolutely wrong. It means a word document that was modified a week ago will now have today's sync date attached to creation, modification and last accessed.

I followed the recommendation by xCSxXenon and reverted to FreeFileSync 12.5.

I carried out another sync and the target now has the same and correct dates and times as the source.

So I updated to 13.1 again and after another sync the target again receives the date and time stamp of the sync for all three date / time fields.

This should be easily reproducible by anyone to verify.

Best moongate

[moongate]

Thinking about this maybe it is possible to turn this bug into a feature of selecting if original dates/times should be synced or if sync time should be used.
I could see a use case for each one of those scenarios if optional.

[xCSxXenon]

Sounds like a BUG
@Zenju Anything you can think of that would lead to this behavior? Maybe another weird Apple thing since that is all too common?

[moongate]

Sounds like a BUG
@Zenju Anything you can think of that would lead to this behavior? Maybe another weird Apple thing since that is all too common?

Please keep in mind that sr21ffs reporting the issue in general discussion and varez in this thread are reporting the issue on macos.

But I am having the same issue running on Windows 11 ;-)

[Zenju]

No changes on macOS, but Windows file copying indeed got changed a bit. Instead of redundantly setting modtimes during file copy and also directly after, FFS 13 extracts the file handle from the copy routine, so that modtimes are practically only set once.
However it seems this duplicate second access is needed to get around driver/buffering bugs on certain external hardware.

@moongate: Here's a FFS 13.2 beta. Does copying file times work again for you with this version? https://www.mediafire.com/file/ogumvwhb6kmop9j/FreeFileSync_13.2_%255BBeta%255D_Windows_Setup%25283%2529.exe

[dennisb]

I had the same problem that I originally attributed to syncing to a Cryptomator vault on a NAS. This beta version fixes it.

[moongate]

Hello Zenju,

thank you for the explanation and for getting back so quickly.

I did one more confirmation run with 13.1 to make sure the issue is currently present and it was.

Running the same sync with 13.2 beta is resolving the issue.

As dennisb is pointing out syncing against a NAS etc might be involved here - but then again it did not formerly trigger this misbehavior with 12.x.

Best moongate

[Zenju]

FWIW not setting modtime correctly in FFS 13.2 is certainly a bug outside of FFS. But if FFS can offer a workaround by reverting to the old behavior, so be it.

[therube]

but Windows file copying indeed got changed a bit

Should that not be documented in the change log?
Not necessarily in detail or anything, but at least on a conceptual level?

That way when one looks (& assuming they do) at the change log & then sees of or hears of issues, they can say, "oh I wonder if".

[Zenju]

FreeFileSync 13.0 [2023-09-12]
------------------------------
Avoid redundant file reopen when setting file times during copy

[therube]

Heh. OK, then maybe a bit more detail, explanation, might be needed ;-).
(When I looked, just now, I looked at 13.1 changes. And when I looked at 13.0's it must not have "clicked" as to what that might or might not have meant.)

[Simtob76]

Is it possible to get FFS 13.2 beta also for mac?

[Zenju]

There weren't any changes on the macOS side.

[sr21ffs]

I went back to version 13.0 in macOS and the problem is gone now (at least, for the moment). It seems to me that there is something off with version 13.1 in macOS. Maybe some of the other users that also had problems with the macOS version could verify if going back to the previous version also works for them.

[moongate]

I am still running on 13.2 Beta as is was correctly syncing the dates after testing.

As this is the first time I am in this position with freefilesync I also have two remaining questions.

How long does it usually take after identifying such an issue until it is rolling into a stable release 13.2?
Did the Beta that I installed over my donation version remove the benefits of that version?

[therube]

Did the Beta that I installed over my donation version remove the benefits of that version?

Yes (it "removed" them).
See if Donation features are available in the Beta (like, I think Parallel under Comparison settings).

[sr21ffs]

I went back to version 13.0 in macOS and the problem is gone now (at least, for the moment). It seems to me that there is something off with version 13.1 in macOS. Maybe some of the other users that also had problems with the macOS version could verify if going back to the previous version also works for them.

Anyone with macOS who has experienced the same situation (version 13.0 working fine but version 13.1 showing the problem mentioned in this thread)? Now I'm OK with version 13.0, but it would be great to be able to update to future versions.

[moongate]

For me this is the first time I did interact with the forum for an actual issue that is not only cosmetic but decides wether I could use FFS productively or not.

I am pretty impressed with the process implemented by FFS with a moderator (xCSxXenon) pre-qualifying the issue and shortly after (Zenju) jumping in to follow up and provide a beta that eliminates the issue.

What I am currently puzzled about is when the beta will convert into the next stable release.
13.1 came out exactly 4 weeks ago on October 23rd
13.0 is from September 10th
12.5 was available on July 25th

So if I had to guess every month there is a release. Will this also be true for 13.2 in November?

[xCSxXenon]

Just to clarify, I am not a moderator with any extra permissions or anything, I just have a passion for FOSS and like helping others looking for help!
FFS averages around a release per month, but time isn't what dictates releases. Zenju seems to pick a list of bugs/features to work on and then release a version only when all of those bugs/features are finished. That's how I interpret it at least

[moongate]

Hello xCSxXenon,

in that case I have to thank you even more for voluntary providing your support to forum visitors.
Your initial tip from post #2 of reverting to a lower version to check if this would change the behavior was so helpful and pointed in the right direction so quickly.

Also thank you for elaborating on my release question, much appreciated!

[AnK]

Hello, refreshing the thread.

I do replicate the same issue (using version 13.3) in very specific scenario on Windows 11. I have investigated a bit more and below are my findings.

When syncing two folders A and B where A is locally stored one and B falls down into one of the following scenarios:
1) folder B is stored locally
2) folder B is stored on NAS mounted with native Windows method
3) folder B is stored on cloud drive (tested with GoogleDrive) mounted with vendor provided tool (GoogleDrive for Windows desktop)
4) folder B is stored on cloud drive (tested with GoogleDrive and OneDrive) mounted with third party tool Mountain Duck.

In scenarios (1), (2), (3) - the files are synced properly between A and B.

In scenario (4), when syncing files with FreeFileSync the modification date / time of the file is modified to the syncing moment. Which affects the whole process. Effectively all the missing and different files get copied. But as they get the modification date reset to the syncing moment - they will be included in every future syncing again. The main issue with that is that causes unnecessary network traffic.

As that issue is not replicated in (2) and (3) it could indicate that the problem is related with the mounting tool used in scenario (4) (here Mountain Duck). But on the other hand copying files with e.g. Windows explorer - transfers the files with a proper date / time modification stamp.

[therube]

(No clue about it, much less the difference between cyber & mountain, but...)

https://github.com/iterate-ch/cyberduck/discussions?discussions_q=is%3Aopen+date

https://docs.cyberduck.io/protocols/s3/#modification-date

[Malcorvus]

Hello.

I'm refreshing this thread because I face the same issue. I'm using FSS 13.4 on Windows10. Folder A is locally stored. Folder B is on OneDrive mounted with third party tool (here RaiDrive). Modification date is modified to the syncing moment. Is there a solution yet? Thanks for your help.

[Lady Fitzgerald]

I'm having the same problem in Linux Mint. I want to use FreeFileSync (FFS) to sync between two computers using backup drives. When I backup data to a backup drive on Computer 1, the time and date of the file that gets written to the backup drive is the time and date of the backup. Normally, this isn't a problem but, when I try to sync the backup drive to Computer 2, the changed times and dates results in every file on the drives being rewritten, with new time and dates, of course (eye roll).

I could reset the syncs to be based on content and file size but, when dealing with four 8TB drives, that would take ten to sixteen hours before any actual writing takes place.

How can I get FFS to not change the time and date of files?

[xCSxXenon]

How can I get FFS to not change the time and date of files?

FFS doesn't change file metadata, except to correct it. When FFS transfers a file, it will have the wrong modification time, and then FFS corrects it. If FFS can't correct it, something is preventing it. Phones using MTP are a common occurrence of this, and there is nothing FFS can do because it is a limitation of the protocol. Another cause is using a filesystem format that doesn't support it either, which may be your issue

[therube]

@Malcorvus, if you manually copy (via Windows Explorer) a local file to OneDrive (via RaiDrive), what date/time does OneDrive get?

[Teoma]

Hi everyone,
first of all, I absolutely love FFS! I've checked out 2 or 3 other file syncing apps, and this one definitely wins in terms of user friendliness and performance.
So, I'm experiencing the same issue:
- using macOS Sonoma 14.4.1
- FreeFileSync 13.5 donation edition
- VeraCrypt 1.25.9
- syncing 2 VeraCrypt containers: 1 is on a NAS (buffalo networked attached storage) and one is on the SSD harddrive of my Mac
When doing a Sync, FFS sets the modification date to the time of syncing.

[xCSxXenon]

VeraCrpyt has been known to cause that issue
search.php?keywords=veracrypt

[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