I am trying to run ChronoSync in order to use my database on two machines, but I keep getting this error,
The operation failed because the user does not have the correct access to the file or folder.
Occurred while copying to file:
/Volumes/DevonThink Boenning/Boenning.dtBase2
I am assuming this is a simple fix. Any help would be appreciated.
Thanks
PS - Can’t wait for the iPad app!
I assume this is an error you are seeing in ChronoSync?
ChronoSync’s Help has very good and concise information on ensuring your machines are properly configured for file sharing, permissions, etc. For example, the error you see can occur when the target machine is offline or not properly connected to your local network. It also can happen if the target folder was moved. I often find that opening “Choose” in the left- or right-hand target in a synchronizer document and browsing to the proper folder can fix this error.
Sounds to me like a permission problem, did you look in file>get info yet? You should be able to read&write. I have had these errors with chronosync too and this fixed it.
I understand that there is no native auto-sync for DTPO available between 64-bit Macs (yet). Is this correct? We have been using ChronoSync over a local network instead. It all seems to work very well, BUT all of the multi-page PDFs come over as just one page. That is, the first page is Ok, but the rest are missing on the target database. Any ideas why could that be occurring and what could be done about it? (And yes, we have already submitted the same question to Econ Technologies support).
Or are there some other preferable, functioning DTPO DataBase sync methods?
This is unfortunate. I’ve used CS several times daily for years to sync databases of PDFs and have never seen this. PDFs are unitary files – all the pages are in the same file. It would be helpful if you post back here if Econ Technologies is able to resolve the question.
There is a DEVONtech sync product in beta testing. Public betas have been released - the most recent one in June, I believe. Because progress on that beta has undoubtedly made the June version OBE, you might want to write DEVONtech support directly (support@devontechnologies.com) for further updates about the beta tester program.
Thanks Korn,
1). Econ support responded. ChronoSync problem solved (user error). 
2). Last time I checked, the Devonian blog posts stated that the DT/PO sync plug-in (public beta) is 32-bit only (initially).
3). But there are probably several other sync options out there.
When it’s released, the next public beta of the DEVONthink Sync plugin will run in 64-bit mode. (We don’t project release dates.)
For the record, like Korm I have used Chronosync and DTPO together for years without problems. Chronosync also has good support.
It looks deceptively simple and indeed often the simple setups work really well. But familiarize yourself with the “dissect packages” option in CS, this may be relevant because Devonthink’s databases are just that, Unix packages.
Ticking that box makes Chronosync behave very differently. Desirable at times but make sure you know what you are doing and always do a trial sync before committing to a sync action. You should only ever see operations going one way, never bidirectional criss-crossing.
HTH
Prion
Quote: “You should only ever see (ChronoSync) operations going one way, never bidirectional criss-crossing.”
Good advice, thanks. Thou I thought the “always use newer update” option (in CS) might make that x-cross process safer.
I’ve been using Chronosync with no issues at all. I have Chronosync installed on my main computer which is an iMac and Chronoagent installed on my MB Air ($10). The only thing that I see as concern is as the database grows in size it sync’s could start getting lengthy.
I also use Chronosync to sync other things on my machine and again I’ve had no problems. Running it with a Chronoagent on the remote does improve performance, provides security etc.
I don’t go that way.
There is a reason databases set the bundle bit and hide an extensive folder structure containing the database itself, index files, and the resources (=files) managed in the database etc inside a monolithic bundle. Each of these need to be the version that corresponds exactly to the other items. An otherwise intact database pointing to an item that does not reside exactly at that location or which does not contain the information indexed elsewhere is still broken.
If you are very consistent and always make sure that everything is synced to the newest version before opening a database then letting CS always choose the newest version of the file will always be the right thing.
Not everyone is perfect, though, and running the trial sync and manually looking for bidirectional rather than unidirectional sync operations provides an extra layer of security.
The “always use newest” would have amalgamated the newest version of the database, indexes and resources from different sources, yes, but they would not have complemented each other.
Call me paranoid but with databases I’d rather be safe and it just takes one extra click after making sure that files and databases are synced in the same direction.
Prion
Hi Prion, thanks for the advice.
Had a problem the other day when one Mac crashed (for other unrelated reasons) during the CS sync process. I checked and the DTP databases seem to be fine, but it could have turned out much worse. So yes, a database backup followed by a CS one-way sync is probably the way to go.
Is there any reason to use ChronoSync (for DevonThink) now that DTP v2.51 Sync is released, running and working well?
Not to be pedantic, but at the Unix level there are no packages (at least not in the sense in which a DEVONThink database is a package), only files and folders. Packages exist at the OS X level only. At the Unix level a package is just a folder. Because a package should not be treated a a folder but as a file with data, Unix sync utilities and sync servers (such as Dropbox) easily corrupt DEVONThink databases. ChronoSync treats packages by default as files (as it should) but you can make ChronoSync behave as a Unix sync utility by enabling ‘dissect packages’. This is not recommended unless you know what you are doing and are able to stick to a very rigid sync discipline.
Unfortunately if ‘dissect packages’ is selected making sure that you never do bidirectional criss-crossing is not enough to assure that everything goes well.
Suppose you have a database (package) with two documents B and C and one administrative file A (the administrative file maintains the location of B and C, the index, metadata and so on). Represent this as [A, B, C]
Now suppose you modify B in the source. This changes not only B but also A. So the source becomes [A’, B’,C].
Then you add D to the target. This too is accompanied by a change in A. So the target becomes [A", B,C,D].
Now you do a trial sync. You will find that A’ conflicts with A", that B’ will be transferred from source to target and D from target to source. You let ChronoSync solve all problems by syncing from source to target (once only). Now the source remains [A’,B’,C] and the target becomes [A’,B’,C,D].
Now there is a problem: the target contains a document (D) that is not registered in its administrative file (A’), so it will not be found in searches, it is not available to DEVONThink’s artificial intelligence, you will not find it in the group hierarchy and so on. You may not be aware of that problem if you forgot that you added D, but it still exists.
Furthermore, next time you sync the other way round the source will have the same problem!
This is why, in the previous comment, I emphasized that packages do not exist at the Unix level! At the Unix level a sync utility or sync server cannot know that a DEVONThink database should be treated as a file rather than a folder and so any form of Unix syncing (whether it be Dropbox sync or ChronoSync sync with dissect packages) might easily lead to problems.
If there were a bundle bit, packages would be recognizable at the Unix level. Unfortunately, there isn’t such a bit. Packages distinguish themselves from folders only because their extension (in the case of a DEVONThink database: .dtBase2) is registered in the application’s (in this case: DEVONThink’s) information property list. So to distinguish a package from a folder, a file utility must check (in one way or another) the information property lists of all your applications. OS X provides routines for doing so, but Unix doesn’t. That’s why Unix level sync utilities (including ChronoSync with dissect packages selected) will never be able to sync DEVONThink databases properly.
So if you are paranoid about your database, don’t know very well what you are doing, or are not very disciplined, you should not select ‘dissect packages’ if you use ChronoSync to sync your DEVONThink databases.
File sync servers such as Dropbox would only be able to treat packages as such if they would have the information property lists of all Mac OS X applications.
To sum up my point: DEVONThink sync and ChronoSync sync without dissecting packages are pretty safe, whereas putting your database on Dropbox and ChronoSync sync with dissect packages might easily corrupt your database.
See
developer.apple.com/library/mac/ … ction.html
and, especially,
developer.apple.com/library/mac/ … -CH106-SW1
for more information about packages.
Arnow:
My computer A (source) sync my Devonthink database to computer B (target) using Chronosync. I never change anything on Computer B (target), all the changes to the database in executed in computer A. I am using dissect packages and using the “backup” option in Chronosync to sync computer A to computer B. I have read through your examples about syncing, both in this tread and in a previous thread, and you give examples of situations changing databases on two computers and then sync.
What could go wrong by applying dissect packages and exclusively perform the sync unidirectionally and always from same computer (in my case computer A, the source) ?
In my previous comments I assumed that ChronoSync is used to synchronize a database on two or more computers (either by bidirectional syncs or by alternating left to right and right to left backups). However, as you indicate, if ChronoSync is used to mirror a database on another computer (that is if you always backup in the same direction, synchronize deletions and do not modify the target) there is nothing wrong with dissecting packages. On the contrary in that case it seems to me the preferred option (because it is faster, both compared to DEVONThink sync and to ChronoSync without dissecting packages).
In that case there is also no need to do a trial sync each time you back up.
It is best to sync only when the database is closed on both computers, but if, by accident the source database is open you can simply ignore the errors you get when opening the target database. If the target database is open when the sync starts it might crash, but these problems will be disappeared when you reopen it after the sync.
If you always back up in the same direction and synchronize deletions even modifying the target will not cause troubles except that you loose all the modifications at the next sync (it cannot corrupt your database).
Thanks for the correction!
Comment: I have no problem with korm’s decision to keep using ChronoSync, as he has a well-tested workflow that works for him.
For reasons including (but not limited to) the way Dropbox handles DEVONthink package file databases, we don’t recommend running databases directly in Dropbox. The Sync procedure doesn’t upload a package file to Dropbox, and works around other issues that have been identified with Dropbox. Think of it as uploading to Dropbox a “store” of the database contents and metadata (that first upload may be lengthy for a large database). Then a Mac using that database can Sync to Dropbox, receiving any changes that have been made in the store and uploading to the store changes made on that Mac’s database. So Sync is an incremental procedure. Sync can be invoked manually or on a set schedule.
Sync isn’t limited to “cloud” sync, but can also be done among Macs in a local environment, which I generally prefer. Indeed, one might choose to sync some databases via the cloud and others via direct connection.
Sync doesn’t require third part software.
Sync provides for sharing databases among multiple users. It does not, however, simultaneously update multiple users. Successful use of database sharing in a workgroup will require understanding both of Sync’s capabilities and its limitations. For example, if an important document is added to or modified in a database, external communications would be required to alert the members of the workgroup. Individuals should be designated as having decision-making authority for certain purposes, such as the content and updating of a certain operating procedures document, or the structure of the database – otherwise, chaos could result. (I once took on the job of supervising the development of hundreds of technical SOPs (Standard Operating Procedure) documents for an agency. Individuals were designated as having the authority and responsibility for development, approval (including review and comment by others) and maintenance (including responsibility to ensure the SOP is followed by others) and updating of each SOP. Rules and their enforcement (including an SOP for SOPs 
) were necessary to result in success. At times this felt like trying to herd cats. But the job got done.)
Please don’t regard Sync as a backup procedure. I continue to use Time Machine and Database Archives for backups.