I use with great satisfaction FFS to synchronize my local directories to cloud (pCloud to be precise).
I use compare file size and time then mirror. Also, to be sure, the ignore time shift is 1:30.
But for some file, always the same files, it asks for copy even if they are identical and the cloud version is newer.
For example:
Left:
D:\Research\done-archive\moin-1.8.0\wiki\htdocs\applets\FCKeditor\editor\filemanager\browser\default\frmupload.html
3707 17/11/2008
Right:
P:\wsbackup\d\Research\done-archive\moin-1.8.0\wiki\htdocs\applets\FCKeditor\editor\filemanager\browser\default\frmupload.html
3707 18/6/2020
If I ask to sync and then compare again, the file is there again. Obviously if I delete the copy on the cloud, It is copied with the local disk date and the problem is solved.
Why don't mirror in this case or at least show a warning?
Thanks!
mario
Wants to mirror identical files
- Posts: 9
- Joined: 23 May 2022
-
- Posts: 2946
- Joined: 22 Aug 2012
Your problem description is not completely clear (at least to me).
> But for some file, always the same files, it asks for copy even if they are identical and the cloud version is newer
This part is clear:
If you run a Mirror sync from D:\[SomePath1] to P:\[SomePath2], after a sync the content of P:\[SomePath2] will be identical to that of D:\[SomePath1].
So, if pre-sync P:\[SomePath2] comprises files with a more recent date that those on D:\[SomePath1], the files on P will be overwritten by those on D, even if a file on P is more recent than the one on D.
This is the nature/definition of a Mirror sync, and will not raise a warning (at least not in FFS).
> If I ask to sync and then compare again, the file is there again.
This part is not clear.
If the dates are different and after the Compare FFS suggests to copy left-to-right and you run the sync, is the file actually copied left-to-right? And if so, is the date of the right-side file then 1) the same as the (older) left-side date, 2) still the same right-side date, or 3) a newer right-side date?
In case of 1) everything works as it should
In case of 2) the file on P may be locked and can not be updated/overwritten.
In case of 3) it is very likely an issue of Pcloud not being able to (when necessary) changing file dates when files are overwritten.
You should also check what the what FFS sync log say about such a file.
> Obviously if I delete the copy on the cloud, It is copied with the local disk date and the problem is solved.
This suggests that for "new" files Pcloud correctly duplicates the original file-date.
Do you know what caused the filedate on P to be more recent than the one on D?
If you always want to retain files on P if they have a more recent date, consider using the Update sync variant or define your own Custom sync variant, instead of using the Mirror variant.
> But for some file, always the same files, it asks for copy even if they are identical and the cloud version is newer
This part is clear:
If you run a Mirror sync from D:\[SomePath1] to P:\[SomePath2], after a sync the content of P:\[SomePath2] will be identical to that of D:\[SomePath1].
So, if pre-sync P:\[SomePath2] comprises files with a more recent date that those on D:\[SomePath1], the files on P will be overwritten by those on D, even if a file on P is more recent than the one on D.
This is the nature/definition of a Mirror sync, and will not raise a warning (at least not in FFS).
> If I ask to sync and then compare again, the file is there again.
This part is not clear.
If the dates are different and after the Compare FFS suggests to copy left-to-right and you run the sync, is the file actually copied left-to-right? And if so, is the date of the right-side file then 1) the same as the (older) left-side date, 2) still the same right-side date, or 3) a newer right-side date?
In case of 1) everything works as it should
In case of 2) the file on P may be locked and can not be updated/overwritten.
In case of 3) it is very likely an issue of Pcloud not being able to (when necessary) changing file dates when files are overwritten.
You should also check what the what FFS sync log say about such a file.
> Obviously if I delete the copy on the cloud, It is copied with the local disk date and the problem is solved.
This suggests that for "new" files Pcloud correctly duplicates the original file-date.
Do you know what caused the filedate on P to be more recent than the one on D?
If you always want to retain files on P if they have a more recent date, consider using the Update sync variant or define your own Custom sync variant, instead of using the Mirror variant.
- Posts: 9
- Joined: 23 May 2022
Thanks Plerry! The first part is exactly what I expect by mirroring. But it does not happen.
FFS log says it has copied the file to right side, But on the right side the file does not change. This way, if I redo the sync, FFS has to copy again the file.
At this point I don't think FFS has problems. But to argue with pCloud I need all the info I can collect. Maybe a debug log or something similar.
Thanks for your help!
mario
FFS log says it has copied the file to right side, But on the right side the file does not change. This way, if I redo the sync, FFS has to copy again the file.
At this point I don't think FFS has problems. But to argue with pCloud I need all the info I can collect. Maybe a debug log or something similar.
Thanks for your help!
mario
-
- Posts: 4867
- Joined: 11 Jun 2019
It looks like pCloud is mapped as P:\?
It sounds like FFS is trying to update the metadata of that file, but maybe pCloud isn't supporting that function. Of course, deleting it from the cloud will then re-copy to file with the updated metadata.
It sounds like FFS is trying to update the metadata of that file, but maybe pCloud isn't supporting that function. Of course, deleting it from the cloud will then re-copy to file with the updated metadata.
- Posts: 9
- Joined: 23 May 2022
Yes! This could be the cause. Thanks xCSxXenon.
Indeed pCloud is mapped to P:\ by their app pCloud Drive. FFS syncs D:\... on the left with P:\... on the right.
Do I understood correctly that, if only the file metadata is different, FFS does not copy the file, simply update the metadata?
If it is so, which is the system call used, so I could report to them?
Thanks!
mario
Indeed pCloud is mapped to P:\ by their app pCloud Drive. FFS syncs D:\... on the left with P:\... on the right.
Do I understood correctly that, if only the file metadata is different, FFS does not copy the file, simply update the metadata?
If it is so, which is the system call used, so I could report to them?
Thanks!
mario
-
- Posts: 4867
- Joined: 11 Jun 2019
Zenju would need to confirm that behavior to go further, I'm just a user. The source code is available, but I don't know if you want to dig through that to find out
-
- Site Admin
- Posts: 7506
- Joined: 9 Dec 2007
If a difference is detected (e.g. size or date by default) FFS will copy the file again. If no error occurred, one can expect that the next comparison will not find differences anymore.
If there are differences, it might be because some other software was meddling with the copy operation, e.g. https://freefilesync.org/faq.php#different-after-sync
If there are differences, it might be because some other software was meddling with the copy operation, e.g. https://freefilesync.org/faq.php#different-after-sync
-
- Posts: 4867
- Joined: 11 Jun 2019
Ah, so 'updating' a file is actually copying the new one over then replacing
- Posts: 9
- Joined: 23 May 2022
Solved. The problem was a corrupted database in pCloud client. Recreated it and all these problems disappeared. I'm sorry I doubted of FFS! You know, when the problem is on the interface between two systems it is difficult to establish who is to blame.
Thanks for your patience.
mario
Thanks for your patience.
mario
