Hi,
Is it possible to sync 2 folders at different locations?
What I want is this:
1 - Scan folder (home location)
2 - Save sync info to usb drive
3 - Take usb drive to other location
4 - Scan folder at other location
5 - Compare sync info from home folder with sync info from other location
6 - Sync all necessary data to usb drive
7 - Take usb drive home
8 - Sync all data from other location to home folder
9 - Copy all necessary data from home folder to usb drive (since the program
can now compare it to the sync info from other location)
Is this possible?
Sync 2 folders on different locations
-
- Site Admin
- Posts: 7052
- Joined: 9 Dec 2007
No that's not possible. Nevertheless this is an interesting usecase. I
personally sometimes have the requirement to sync two external hard drives,
but are only able to connect one of them to the pc at a time.
A procedure like above could solve this. Technically it could be implemented
like the sync.ffs_db files, which more or less contain the folder structure.
But the main issue is how to integrate this seamslessly into FFS GUI and FFS
processes. There are a number of constraints which complicate things, e.g.
copying a file to such a "virtual folder" is not possible, deletions, handling
of sync.ffs_db file etc.
personally sometimes have the requirement to sync two external hard drives,
but are only able to connect one of them to the pc at a time.
A procedure like above could solve this. Technically it could be implemented
like the sync.ffs_db files, which more or less contain the folder structure.
But the main issue is how to integrate this seamslessly into FFS GUI and FFS
processes. There are a number of constraints which complicate things, e.g.
copying a file to such a "virtual folder" is not possible, deletions, handling
of sync.ffs_db file etc.
I have tried doing the above Mr. tomkorver and found it impossible. I
synchronized the folder in my USB Removable Drive with that of my Work PC
properly. I brought the Removable Drive home, tried to synchronize it with the
folder in my laptop and found that the program could not establish the
previous comparison it had done with the Work PC. I have deleted and moved
some files previously (and syncd between the Removable Drive and Work PC). The
comparison output suggests the creation of files in the folder in which such
do not exist. I think there is no exact correspondence among the three file
locations. Is there already a solution/feature for this specific task Mr.
Zenju? Thank you!
synchronized the folder in my USB Removable Drive with that of my Work PC
properly. I brought the Removable Drive home, tried to synchronize it with the
folder in my laptop and found that the program could not establish the
previous comparison it had done with the Work PC. I have deleted and moved
some files previously (and syncd between the Removable Drive and Work PC). The
comparison output suggests the creation of files in the folder in which such
do not exist. I think there is no exact correspondence among the three file
locations. Is there already a solution/feature for this specific task Mr.
Zenju? Thank you!
-
- Site Admin
- Posts: 7052
- Joined: 9 Dec 2007
Quote "No that's not possible" ...... at least right now.
-Zenju
-Zenju
I have found another way around the hedge on this, which some might have
already tried. What I did was copy the ffs database file from the updated
location to the folder I want updated replacing the existing ffs database
file. The comparison output was different (given the different db file) but
might actually work upon visual inspection of some files. I will update this
post as I have not tried synchronizing with my crucial data. This seems
backward but probably worth a try on my part. Any insights sirs?
already tried. What I did was copy the ffs database file from the updated
location to the folder I want updated replacing the existing ffs database
file. The comparison output was different (given the different db file) but
might actually work upon visual inspection of some files. I will update this
post as I have not tried synchronizing with my crucial data. This seems
backward but probably worth a try on my part. Any insights sirs?
-
- Site Admin
- Posts: 7052
- Joined: 9 Dec 2007
>copy the ffs database file
This cannot work correctly: the db file keeps entries in relation to both(!)
input directories. Consequently it cannot be used to sync two distinct data
sources via a carrier device (usb stick).
In general copying the db file is something FFS should prevent with an error
message. However it's not easy to detect this kind of situation by the
program.
This cannot work correctly: the db file keeps entries in relation to both(!)
input directories. Consequently it cannot be used to sync two distinct data
sources via a carrier device (usb stick).
In general copying the db file is something FFS should prevent with an error
message. However it's not easy to detect this kind of situation by the
program.
- Posts: 8
- Joined: 8 Jun 2011
Interesting. I had been doing this for quite some time successfully and only
recently did I start getting errors reported due to the incompatible format of
the sync db. Came here to check what had changed.
The only thing I can think of that may have changed at my end (apart from the
regular updates to ffs) was that I may have switched the office machine from
the 32bit to the 64bit version to match the home pc though I think I did that
because of these errors.
I'm am seeing an old sync.x64.ffs_db file that doesn't seem to have been
updated since march. Just thinking with my fingers.. but could it have been
the two versions used to use different db files and that was the reason it
used to work?
If so I'd love to have a setting (manual or otherwise) that enable the
addition of a unique id to the sync.fs_db file for each install so I could re
enable that functionality. Supported or otherwise :)
Great program otherwise and I'd really like to continue to use it. Thanks for
all your excellent work.
recently did I start getting errors reported due to the incompatible format of
the sync db. Came here to check what had changed.
The only thing I can think of that may have changed at my end (apart from the
regular updates to ffs) was that I may have switched the office machine from
the 32bit to the 64bit version to match the home pc though I think I did that
because of these errors.
I'm am seeing an old sync.x64.ffs_db file that doesn't seem to have been
updated since march. Just thinking with my fingers.. but could it have been
the two versions used to use different db files and that was the reason it
used to work?
If so I'd love to have a setting (manual or otherwise) that enable the
addition of a unique id to the sync.fs_db file for each install so I could re
enable that functionality. Supported or otherwise :)
Great program otherwise and I'd really like to continue to use it. Thanks for
all your excellent work.
-
- Site Admin
- Posts: 7052
- Joined: 9 Dec 2007
> Interesting. I had been doing this for quite some time
This is technically undefined behavior which may very well appear to do the
right thing. The most apparent consequence is: Two datasources having both a
copy of the same sync.ffs_db file are seen as only one by a third data source.
Here is one possible problem I see right now:
Assume all three datasources A, B, C are in sync, two of which (A, B) have a
copy of the same sync.ffs_db file.
A file is changed in A then A and C are synced.
Then an equally named file in B is changed.
Now B and C are synced: Looking at the database file, there is had been no
change in C (this is wrong! C thinks it is syncing against A, but it is not!),
but one change in B. Consequently the changed file from B is copied over to C
-> possible data loss! This should have been a conflict "changed on both
sides".
> I could re enable that functionality
What functionality? There is not benefit for copying the db file, but some
risk of misfunctioning.
This is technically undefined behavior which may very well appear to do the
right thing. The most apparent consequence is: Two datasources having both a
copy of the same sync.ffs_db file are seen as only one by a third data source.
Here is one possible problem I see right now:
Assume all three datasources A, B, C are in sync, two of which (A, B) have a
copy of the same sync.ffs_db file.
A file is changed in A then A and C are synced.
Then an equally named file in B is changed.
Now B and C are synced: Looking at the database file, there is had been no
change in C (this is wrong! C thinks it is syncing against A, but it is not!),
but one change in B. Consequently the changed file from B is copied over to C
-> possible data loss! This should have been a conflict "changed on both
sides".
> I could re enable that functionality
What functionality? There is not benefit for copying the db file, but some
risk of misfunctioning.
- Posts: 8
- Joined: 8 Jun 2011
Sorry, might not have made myself clear. Also not exactly sure if it'll work
but here goes anyhow.
Three data sources. A, B & C. Two pairs of sync databases.
In this case A is sync'd to B and B is sync'd to C.
There would exist one sync.ffs_db for the A-B sync. Let's call it
sync_AB.ffs_db.
Also there would exist a second sync.ffs_db files for the B-C sync. Let's call
it sync_BC.ffs_db
When a file is changed on A. It'll get sync'd to B on the next AB sync. And
then to C on the next BC sync. If the same file is changed on A & C. The first
AB or BC sync would move the file to B. And the second sync would register the
conflict.
I'm pretty sure this was how it was working for me when AB was using
sync.ffs_db and BC was using sync.x64.ffs_db. B - my portable USB drive. Had
both sync.ffs_db and sync.x64.ffs_db on it.
Does that make sense? It was working fine for me for a long time and the
behavior had been quite predictable.
but here goes anyhow.
Three data sources. A, B & C. Two pairs of sync databases.
In this case A is sync'd to B and B is sync'd to C.
There would exist one sync.ffs_db for the A-B sync. Let's call it
sync_AB.ffs_db.
Also there would exist a second sync.ffs_db files for the B-C sync. Let's call
it sync_BC.ffs_db
When a file is changed on A. It'll get sync'd to B on the next AB sync. And
then to C on the next BC sync. If the same file is changed on A & C. The first
AB or BC sync would move the file to B. And the second sync would register the
conflict.
I'm pretty sure this was how it was working for me when AB was using
sync.ffs_db and BC was using sync.x64.ffs_db. B - my portable USB drive. Had
both sync.ffs_db and sync.x64.ffs_db on it.
Does that make sense? It was working fine for me for a long time and the
behavior had been quite predictable.
- Posts: 8
- Joined: 8 Jun 2011
Was trying to work out if the easiest option might just be to revert back to
the version before the x64 db rename and found a feature request (Option to
change database filename in GUI and BATCH settings - ID: 2963611) where I
think you explain how what used to work for me came into existence.
[404, Invalid URL: https://sourceforge.net/tracker/index.php?func=detail&aid=2963611&group_id=234430&atid=1093083]
(I had written more but since I wasn't having luck making it clear even to
myself I think I'll just leave it at that for the moment)
the version before the x64 db rename and found a feature request (Option to
change database filename in GUI and BATCH settings - ID: 2963611) where I
think you explain how what used to work for me came into existence.
[404, Invalid URL: https://sourceforge.net/tracker/index.php?func=detail&aid=2963611&group_id=234430&atid=1093083]
(I had written more but since I wasn't having luck making it clear even to
myself I think I'll just leave it at that for the moment)
-
- Site Admin
- Posts: 7052
- Joined: 9 Dec 2007
>Does that make sense? It was working fine for me for a long time and the
behavior had been quite predictable.
This is working, but superfluous. The FFS default logic already does the right
thing also when using multiple sync locations.
> https://sourceforge.net/
This was an issue with binary incompatibilty of different database formats. It
was not a logical issue related to syncing more than 2 data sources.
behavior had been quite predictable.
This is working, but superfluous. The FFS default logic already does the right
thing also when using multiple sync locations.
> https://sourceforge.net/
This was an issue with binary incompatibilty of different database formats. It
was not a logical issue related to syncing more than 2 data sources.
- Posts: 8
- Joined: 8 Jun 2011
Okay.. thought the guys there was having the same issue and the workaround was
to have multiple databases.
If it worked with the single database spread over the three locations that'd
be fine with me.
I now get 'Incompatible sychronization database format: "...."" Setting
default sync.. directions..' everytime for the last few versions.
I presumed it was the three locations workflow that was causing it as sync
will work fine between A-B till I try and resync B-C (less frequent)
>The FFS default logic already does the right thing also when using multiple
sync locations.
So what I am doing, Sync laptop to external usb drive (A-B) then sync usb
drive to desktop at office (B-C) should work fine with the current version and
single db?
Sorry if I'm going on a bit but rather confused and really like the way ffs
worked and want it working again :)
to have multiple databases.
If it worked with the single database spread over the three locations that'd
be fine with me.
I now get 'Incompatible sychronization database format: "...."" Setting
default sync.. directions..' everytime for the last few versions.
I presumed it was the three locations workflow that was causing it as sync
will work fine between A-B till I try and resync B-C (less frequent)
>The FFS default logic already does the right thing also when using multiple
sync locations.
So what I am doing, Sync laptop to external usb drive (A-B) then sync usb
drive to desktop at office (B-C) should work fine with the current version and
single db?
Sorry if I'm going on a bit but rather confused and really like the way ffs
worked and want it working again :)
-
- Site Admin
- Posts: 7052
- Joined: 9 Dec 2007
>If it worked with the single database spread over the three locations
Have you tried it? It is supported by design, everything else would be a bug.
>I now get 'Incompatible sychronization database format: "..
This is a migration issue, related to:
Changelog v3.17
---------------
New database format for <Automatic> mode: a full sync is suggested before
upgrading
Basically all this means is: The db-format will be updated during next sync,
but the (old) database file won't help to determine sync-directions this time.
> should work fine with the current version and single db?
Yes, fully supported.
Have you tried it? It is supported by design, everything else would be a bug.
>I now get 'Incompatible sychronization database format: "..
This is a migration issue, related to:
Changelog v3.17
---------------
New database format for <Automatic> mode: a full sync is suggested before
upgrading
Basically all this means is: The db-format will be updated during next sync,
but the (old) database file won't help to determine sync-directions this time.
> should work fine with the current version and single db?
Yes, fully supported.
- Posts: 8
- Joined: 8 Jun 2011
Tried again and still get the same problem.
Am using 3.17 so deleted all the old database files and laptop/usb/desktop.
Did a full sync from laptop to usb.. did another sync a day later.. worked
fine.
Did a sync from usb to desktop. Worked as expected.
Did a sync from laptop to usb and got the 'Incompatible sychronization
database format' errors again and I had to manually choose which files had
been deleted or moved to prevent having them undeleted or ending up with two
copies.
Both syncs are set to automatic. Both syncs have two directories to sync (one
documents and one pictures) Drive locations and paths are different between
the laptop and desktop but never caused issues before. Could that be it?
Am using 3.17 so deleted all the old database files and laptop/usb/desktop.
Did a full sync from laptop to usb.. did another sync a day later.. worked
fine.
Did a sync from usb to desktop. Worked as expected.
Did a sync from laptop to usb and got the 'Incompatible sychronization
database format' errors again and I had to manually choose which files had
been deleted or moved to prevent having them undeleted or ending up with two
copies.
Both syncs are set to automatic. Both syncs have two directories to sync (one
documents and one pictures) Drive locations and paths are different between
the laptop and desktop but never caused issues before. Could that be it?
-
- Site Admin
- Posts: 7052
- Joined: 9 Dec 2007
>Tried again and still get the same problem.
Can you confirm you are consistently using v3.17 on all your machines? This is
basically the only chance to get this kind of error.
> Both syncs are set to automatic. Both syncs have two directorie
Shouldn't be a problem.
Can you confirm you are consistently using v3.17 on all your machines? This is
basically the only chance to get this kind of error.
> Both syncs are set to automatic. Both syncs have two directorie
Shouldn't be a problem.
- Posts: 8
- Joined: 8 Jun 2011
Yep.. was a version problem. Had the 3.17 installer on the desktop but somehow
must have forgotten to run it :/
All is working and able to sync between the three locations fine again.
Thanks for ya help, ya patience and a great program.
must have forgotten to run it :/
All is working and able to sync between the three locations fine again.
Thanks for ya help, ya patience and a great program.
- Posts: 3
- Joined: 18 Jun 2003
I have another synchronization program (ABSync) that deals with this problem
by generating a "sync ID" for each computer its installed on. The sync.db is
then labeled "ABSync systemid sync name.dat".
That is the only way I know of to properly do a three-way/star sync.
See [404, Invalid URL: http://www.uwe-freese.de/software-projekte/absync/ABSync/absync_bottom.html%23starformationsync]
I would like to see FreeFileSync adopt this method, because almost all of my
sync pairs are three-way/star.
by generating a "sync ID" for each computer its installed on. The sync.db is
then labeled "ABSync systemid sync name.dat".
That is the only way I know of to properly do a three-way/star sync.
See [404, Invalid URL: http://www.uwe-freese.de/software-projekte/absync/ABSync/absync_bottom.html%23starformationsync]
I would like to see FreeFileSync adopt this method, because almost all of my
sync pairs are three-way/star.
-
- Site Admin
- Posts: 7052
- Joined: 9 Dec 2007
A system-unique sync-id is not required. Three-way sync is already supported
by FFS without further ado.
by FFS without further ado.
- Posts: 3
- Joined: 18 Jun 2003
Isn't that what the original post was asking about? I guess I didn't
understand the original scenario.
understand the original scenario.
-
- Site Admin
- Posts: 7052
- Joined: 9 Dec 2007
The original question was about synchronizing distinct data sources by
determining status at each location in isolation, then copying over "the
diff". This is not possible with FFS, at least I don't see a compatible design
that can do this.
Your question was about an ordinary star like sync where all data is available
at the carrier USB? This is supported via <Automatic> mode. The database file
keeps information relative to each sync-pair, so it is possible to e.g. sync
an USB stick against multiple other local computers and "do the right thing".
determining status at each location in isolation, then copying over "the
diff". This is not possible with FFS, at least I don't see a compatible design
that can do this.
Your question was about an ordinary star like sync where all data is available
at the carrier USB? This is supported via <Automatic> mode. The database file
keeps information relative to each sync-pair, so it is possible to e.g. sync
an USB stick against multiple other local computers and "do the right thing".
