Or am I not getting something?
This should never happen -- misdetection
-
- Posts: 66
- Joined: 7 Dec 2016
Or am I not getting something?
Last edited by David.P on 26 Sep 2023, 19:58, edited 2 times in total.
-
- Posts: 3607
- Joined: 11 Jun 2019
Your sync settings are set to copy the left side to the right side, even if the right side is newer. Click the green gear icon and check those settings. Post a screenshot of them here if you aren't able to pinpoint the issue
-
- Posts: 66
- Joined: 7 Dec 2016
I don't think so. My sync settings are standard Two-way, aren't they?
-
- Posts: 3607
- Joined: 11 Jun 2019
Looks correct...
I know you can manually change actions in the comparison results. Maybe there was an accident click that changed it? What if you run a compare again?
I know you can manually change actions in the comparison results. Maybe there was an accident click that changed it? What if you run a compare again?
-
- Site Admin
- Posts: 7052
- Joined: 9 Dec 2007
OP simply copied an older file over a newer one on the left side. This change is then propagated to the right. That's how "Two way" sync works: https://freefilesync.org/manual.php?topic=synchronization-settings
-
- Posts: 66
- Joined: 7 Dec 2016
Whoa! Still not quite sure if this is awesome, or dangerous. Maybe both?
-
- Posts: 3607
- Joined: 11 Jun 2019
That certainly makes it look weird in the compare! I suppose that behavior makes sense, 'two-way' propagates any changes to the other side. I tried to think of situations where this would be an issue, but ultimately couldn't! Thanks Zenju
- Posts: 944
- Joined: 8 May 2006
So Two Way is still working left to right (source/target) for "update" purposes (?) - i.e., where the same file (already) exists on each end - rather then "updating" the latest version, either left to right or right to left, depending on which is newer?
[NO!]
(Oh, I'm confused, heh.)
"This change is then propagated to the right" ... "to flow in both directions"
To me, the former says left to right, & the latter says it could be either way, depending on time/size (or size)? (No idea how Content would work if it could be "either way".)
[That /would/ be the case, if only FFS were involved.]
Oh, so it is this...
"sync.ffs_db ... will be ... used to compare the current file system state against the last synchronization in order to determine the sync directions"
& you're saying that
"OP simply copied an older file over a newer one on the left side"
& when he did this, he did this "manually" - i.e., outside of the purview of FFS, so the "sync.ffs_db" was not aware of the file change, so the sync.ffs_db still had a newer date/size then the target, & so - even though that is not the actual case, it wants copy the older/smaller over top the (truly) newer/bigger file.
So it is actually sync.ffs_db that controls what happens, & if sync.ffs_db is out of sync - for whatever reason.
Ah.
That would never have occurred to me.
(And I'll have to think about that long & hard, cause it is still confusing, to me.)
Oh, this is still boggling my mind, & I'm sure some of what I've surmised, above, is actually wrong.
Has to be wrong!
From this thread, the source data would have to be deleted for FFS to copy those deletion to GDrive, some of what is above is wrong, has to be wrong!
So is "two way" simply an "update" sync - for existing files on each side.
With the addition that, creates/deletes are propagated to each end?
Is that it?
And...
In this particular case, the file was existing on each end - so while the sync.ffs_db was used - but, the OP "manually"... did something (regardless of what that something might have been), copied an older file over an existing - and, did this outside of FFS, so sync.ffs_db was unaware, so on wanting to sync, sync.ffs_db being used, didn't know the difference.
So for existing, same named files on each end, sync.ffs_db is used - regardless of what may be the actually circumstances "on disk".
Is that it?
(I, literally, have a black spot, section, in my brain, & it must be in that spot where I'm missing this.)
[NO!]
(Oh, I'm confused, heh.)
"This change is then propagated to the right" ... "to flow in both directions"
To me, the former says left to right, & the latter says it could be either way, depending on time/size (or size)? (No idea how Content would work if it could be "either way".)
[That /would/ be the case, if only FFS were involved.]
Oh, so it is this...
"sync.ffs_db ... will be ... used to compare the current file system state against the last synchronization in order to determine the sync directions"
& you're saying that
"OP simply copied an older file over a newer one on the left side"
& when he did this, he did this "manually" - i.e., outside of the purview of FFS, so the "sync.ffs_db" was not aware of the file change, so the sync.ffs_db still had a newer date/size then the target, & so - even though that is not the actual case, it wants copy the older/smaller over top the (truly) newer/bigger file.
So it is actually sync.ffs_db that controls what happens, & if sync.ffs_db is out of sync - for whatever reason.
Ah.
That would never have occurred to me.
(And I'll have to think about that long & hard, cause it is still confusing, to me.)
Oh, this is still boggling my mind, & I'm sure some of what I've surmised, above, is actually wrong.
Has to be wrong!
From this thread, the source data would have to be deleted for FFS to copy those deletion to GDrive, some of what is above is wrong, has to be wrong!
So is "two way" simply an "update" sync - for existing files on each side.
With the addition that, creates/deletes are propagated to each end?
Is that it?
And...
In this particular case, the file was existing on each end - so while the sync.ffs_db was used - but, the OP "manually"... did something (regardless of what that something might have been), copied an older file over an existing - and, did this outside of FFS, so sync.ffs_db was unaware, so on wanting to sync, sync.ffs_db being used, didn't know the difference.
So for existing, same named files on each end, sync.ffs_db is used - regardless of what may be the actually circumstances "on disk".
Is that it?
Two way is a "bi-directional sync" - for existing [same named] files on each side - as determined by sync.ffs_db?So is "two way" simply an "update" sync - for existing files on each side.
(I, literally, have a black spot, section, in my brain, & it must be in that spot where I'm missing this.)
-
- Posts: 66
- Joined: 7 Dec 2016
That's too much text 💁🏼♂️
-
- Posts: 2287
- Joined: 22 Aug 2012
What may (correctly) happen in a two-way-sync in case a previous file-version is restored, is discussed before, and probably most accurately described in my reply to that thread.
- Posts: 944
- Joined: 8 May 2006
(
If one cannot relatively easily comprehend an expected outcome, mistakes are apt to happen.
I'm going to have to re-read these threads, multiple times ;-).
)
That's my point.That's too much text
If one cannot relatively easily comprehend an expected outcome, mistakes are apt to happen.
I'm going to have to re-read these threads, multiple times ;-).
)
