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