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!
Incomplete One-Way Sync
- Posts: 11
- Joined: 3 May 2024
- Posts: 3650
- Joined: 11 Jun 2019
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
You can attach files using the "Editor & Preview" below the text box
- Posts: 11
- Joined: 3 May 2024
Thanks. Here's the screenshot:
- Posts: 3650
- Joined: 11 Jun 2019
We'll need the entire window, not a section
- Posts: 11
- Joined: 3 May 2024
Including folder & file names?
- Posts: 11
- Joined: 3 May 2024
Hi, may I cover up the folder & file names that are listed in the window? Thanks.
- Posts: 11
- Joined: 3 May 2024
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.We'll need the entire window, not a section xCSxXenon, 08 May 2024, 21:36
- Posts: 11
- Joined: 3 May 2024
We'll need the entire window, not a section xCSxXenon, 08 May 2024, 21:36
- Attachments
-
- FFS 05.08 Log 2 - Copy 3.jpg (372.52 KiB) Viewed 276 times
- Posts: 11
- Joined: 3 May 2024
Hi, I just installed v13.6--it didn't solve my issues. Please help. Thanks!
- Posts: 2304
- Joined: 22 Aug 2012
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.
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.
Last edited by Plerry on 15 May 2024, 14:59, edited 2 times in total.
- Posts: 3650
- Joined: 11 Jun 2019
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
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
- Posts: 11
- Joined: 3 May 2024
Thank you both. I'll look into the things you mentioned and then report back.
- Posts: 11
- Joined: 3 May 2024
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.
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.
- Posts: 2304
- Joined: 22 Aug 2012
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.
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.
- Posts: 11
- Joined: 3 May 2024
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
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
- Posts: 2304
- Joined: 22 Aug 2012
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?
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?
- Posts: 11
- Joined: 3 May 2024
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
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