C-Command Software Forum

ChronoSynching Between Machines

I need to synch my EF libraries on two machines, preferably with ChronoSync, which I use for lots of things. I am getting very confusing results. What I have been trying to do is synch the two Finder folders that contain the relevant library. The result this morning was that a new variant of the EF library was created inside the Finder folder on one machine (and perhaps both). Thus, within EF’s Files folder, I see Name.eflibrary and 0Name.eflibrary. Also, I see two versions of the To Import folder. All of this creates a lot of confusion and the potential for losing things.

I am sure that there must be a simple and optimal way to do all this, but it eludes me. ??

Additional issues may include (1) permitting or not permitting duplicates, (2) one-way or two-way synchronization, (3) saving deletions. For example, after synchronization, I am seeing a huge number of files in Unable to Import,

The bottom line is that if you do a one-way sync, you don’t sync while the library is open in EagleFiler, and you configure ChronoSync to make one folder an exact copy of the other, everything will work. Unfortunately, with the default ChronoSync options the copy will be different from the original. This will cause problems because it’s equivalent to adding/moving/deleting files behind EagleFiler’s back. Please see these two threads.

I should have added, based on an earlier query, that the problem includes EF having difficulty knowing how to two-way synchronize the .eflibrary files. However, one-way synchronization is obviously dangerous, so it would be nice to be able to do it. Perhaps it is impossible.

To underatand my perhaps erroneous reasoning, suppose we have two computers with identically named EF library files A and A, but with somewhat different files. And suppose which files are newer varies with machine because both have been worked upon since the last synchronization.

Computer 1
A (newer)
a (older)
b (newer)

Computer 2
A (older)
a (newer)

One-way synchronization would replace at least one newer file with an older one.

What would two-way synchronization do? I would expect it to generate, on both machines

A (newer)
a (newer)
b (newer)

However, A(newer) would not be correct because it wouldn’t know about c. If EagleFiler, aware of such issues, tried to cope by keeping both A(older) and A(newer), but with one of them renamed, then there would be other problems. That may be what I’m seeing.

It seems that an ugly “solution” would be, each time:
o Export everything from the EF libraries on both machines, putting results in temporary folders on the two machines
o Two-way synchronize those two folders
o Delete the existing EF libraries on both machines
o Create new EF libraries on both machines, using the previous names
o Import the folders on both machines

That’s beyond the capacity of a simple synchronizer. I also wonder whether such export/import activity is super-reliable.

My hope, then, is that I’m not seeing a simple way around the problem.

Crossed in Ether
I added my addendum before seeing your earlier response. It appears from the other threads that my fears are correct and that the two-way sychronization would indeed require the complicated stuff I describe. That’s not the end of the world, but it’s too bad. I wonder whether a new non-trivial EF feature would be to wake up, observe the existence of unrecognized files in the relevant FInder folder, and ask the user whether those should be imported into EF? If yes, then wouldn’t this solve a number of issues?

This is a general problem that affects nearly every application. You cannot merge changes to two copies of a Word file using file synchronization software, nor can you merge changes to an iPhoto library. With the Word example, the newer file will replace the older one. With the iPhoto example, the newer database that tracks the files will replace the older one, and the merged files/folders will not be consistent with it. So it is with EagleFiler, too.

That’s why you need to use one-way synchronization. And if you don’t want to lose data with one-way synchronization, you should only make changes to one copy of the library before syncing.

This would be reliable in the sense that it would work consistently, but you would lose all the EagleFiler metadata when exporting and importing.

There are a variety of simple ways to make this work. All require that you only modify one side at a time between syncs.

Yes, but that wouldn’t synchronize the metadata properly. And it wouldn’t properly handle files that were moved. Ultimately, even if EagleFiler were smarter, file synchronization software is a crude tool that’s not up to handling this type of task.