Incomplete One-Way Sync

[N. T.]

Hi,

I'm using FreeFileSync version 13.5 on a Windows 10 PC.

I use "File time & size" for comparison, and "Mirror" for sync, to sync a folder on my PC to a folder in iCloud Drive.

I ran into the following 2 issues:

1. After each "successful" sync, there always remain, in the target folder, some "files that will be updated on the right side", and also some "files that will be deleted on the right side". In other words, the target folder remains an incomplete copy of the source folder.

2. After I make changes in a file in the source folder, if I don't change the file's name, FFS doesn't seem to recognize the changes, for it leaves the file in the target folder unupdated. I now have to resort to manually deleting the old file in the target folder, in order to force FFS to sync the changed file to the target folder.

Please advise how these issues may be resolved. Thanks!

[xCSxXenon]

Run a 'compare' and post a screenshot of the FFS window after it finishes.
You can attach files using the "Editor & Preview" below the text box

[N. T.]

Thanks. Here's the screenshot:

FFS 05.08 Log.jpg (168.13 KiB) Viewed 337 times

[xCSxXenon]

We'll need the entire window, not a section

[N. T.]

Including folder & file names?

[N. T.]

Hi, may I cover up the folder & file names that are listed in the window? Thanks.

[N. T.]

We'll need the entire window, not a section

Hi, may I cover up the folder & file names shown in the window, or do you need to see those listed in the screenshot? Thanks.

[N. T.]

We'll need the entire window, not a section

[N. T.]

Hi, I just installed v13.6--it didn't solve my issues. Please help. Thanks!

[Plerry]

For files shown in your picture (some of the 78 files that FFS intends to update left=>right) it seems the size is identical left vs right. So, file size does not seem to be reason for a renewed sync.
You could check the file dates left-vs-right of some of these files. Perhaps iCloud modifies the file date of files in the iCloudDrive (sub)folder. If it does, the file time is different, and thus cause for sync action. And because you run a Mirror sync, it will be a left-to-right update of the right-side file.

As far as the 32 files FFS intends to delete in your ICloudDrive (sub)folder:
It seems those files (not shown in your picture) do exist in the iCloudDrive folder, but not (or no longer) in C:\Users. After you actually run the sync, FFS should have deleted those 32 files in the iCloudDrive (sub)folder; if not it will report the failure to do so in its log-file. You can check yourself right after the sync. Perhaps iCloud restores files that have been deleted.

But possibly you have a more fundamental problem:
Your left base location is "C:\Users" and your right base location
"C:\Users\ \iCloudDrive".
(I suppose the blanks in the latter base location are the result of some blanking for privacy reasons).
Because iCloudDrive is a (sub)subfolder of C:\Users, it is part of C:\Users, and hence there is a partial overlap between your left and right base location.If not dealt with properly, this can cause a perpetuum in sync actions. It will then ultimately create e.g. an iCloudDrive folder somewhere inside your iCloudDrive folder etc.
You can prevent overlaps between your left and right locations by using distinct, separate locations, or by adding an Exclude Filter rule to exclude, in your case, the (highest level) iCloudDrive folder.

[xCSxXenon]

Also, considering they are the same size, it is likely modification time that is changing. The 'source' files may have a timestamp unsupported in the destination (iCloud) and that will cause the timestamp to be set to the date/time of the sync operation. Also, iCloud may do some post-processing that changes the timestamp, thus a difference is created, and then FFS syncs it back to the initial state restarting the cycle.

Plerry does make a good point as well, having a parent directory syncing with/to one of its subdirectories presents some unique challenges that can take some complex/advanced tweaks to get working. What is your end goal here, as there might be a better solution? Why are you storing your data in the Users folder in the first place? This is an awful idea from a technical and organizational perspective, that's what the user library folders are for

[N. T.]

Thank you both. I'll look into the things you mentioned and then report back.

[N. T.]

Hello again.

First, a few questions related to my one-way sync issues:

Would any or all of the following lead to syncing errors in FFS?

1. Having folder/file names in another language than English.
2. Having many folder levels above the source folder (see below).
3. Having a folder in iCloud Drive as the destination folder for one-way syncing.
4. Having this date and time format (set in Windows 10)--e.g., "2024/05/17 周五 下午 1:30" (周五: Friday; 下午: PM).

5. Making small changes in a source file (e.g., replacing a word or two) which don't lead to file size changes.
6. Making changes in a source file on the same day, with editing times that are close together.


Regarding the locations of the source and destination folders, here are their full paths (I've "generalized" the names of the folders/subfolders):

Source folder: C:\Users\username\folder level 1\folder level 2\folder level 3\folder level 4\folder level 5\Poems.

Target folder: C:\Users\username\iCloudDrive\Poems.


Many thanks for helping me with the issues.

[Plerry]

1) Don't know. No experience with that
2) In theory no, but I have seen reports that a total path length over 255 characters caused problems. No clue if any of that is OS or file system related.
3) Don't know. No experience with that
4) That should affect just how date and time are displayed; not how date/time is stored.
5) Such changes are rare, but in any case should still result in a different time-stamp and thus cause a sync action.
6) Only if this results in less than 2 seconds (default) increase the the time stamp.
See FileTimeTolerance.
Or if the time-stamp difference matches exactly the "Ignore Time Shift" setting.

At least, you now seem to have eliminated the (partial) overlap between Source and Target location.

[N. T.]

Hi Plerry, thank you for answering my questions.

Now the question remains how, during a one-way sync, to persuade FFS--

1) To recognize changed files (even though the file names stay the same as before), so that it will sync them to the target folder in iCloud Drive; and

2) To delete from the target folder those files that are no longer in the source folder.


Thanks,

NT

[Plerry]

ad 1)
Was this ever a problem?
You wrote/showed that FFS wants to update files that (in your perception) had not changed.
I don't think you wrote that FFS does not sync files that had changed.

ad 2)
I expect this issue to be resolved by eliminating the overlap between Source and Target.
Can you confirm?

[N. T.]

Thank you again for helping me, Plerry.

Regarding "the overlap between Source and Target", well, it actually never existed: their full paths that I posted (with the folder names "generalized") stay the same as before--in my posted screenshot of the FFS window, I blanked out parts of their paths; sorry for the confusion. So it seems that the locations of the source and target folders didn't cause the incomplete mirror sync.


Regarding the syncing errors--I'm sorry if I didn't present them clearly--they are these 2:

1) FFS doesn't seem to recognize that a file in the source folder has been edited if I don't make changes in the file name as well--even though, obviously, the file's timestamp, and often, file size, have changed; as a result, the changed file is not copied from the source folder to the target folder during a mirror sync--i.e., after a "successful" sync, the older file is found in the target folder, instead the newly edited one. (This issue doesn't seem to occur if I make changes in the edited file's name; in that case, it gets recognized as a changed file, and copied to the target folder during a sync.)

2) When files in the source folder are replaced with newer versions, as well as modified titles, they remain in the target folder along with their newer versions after a mirror sync, resulting in more files in the target folder than in the source folder.

BTW, I've tried the mirror sync with the other 2 comparison methods--"File Content", and "File Size", and ran into the same 2 issues stated above.


Thanks,

NT