I recently purchased DEVONthink To Go for my iPhone and liked it enough to trial DEVONthink Pro Office for my Mac Pro and MacBook Air. I run an ownCloud WebDAV server at home, and really like the self-hosted syncing available for these products!
I think I have a grasp how the database works and syncs while self-contained, but I’m trying to get my head around what happens when I index a mounted volume. I have a 3 TB Samba share on an Ubuntu server on my network, which would be nice to search from my Mac Pro. If I index this, should I expect the database on my Mac Pro to contain only the paths to files (opposed to including file content)? And if I sync this database with my WebDAV server, will only the index data be uploaded? And if I sync this database with my MacBook Air, I’ll potentially have a database with broken files paths, unless I mount the same volume?
And finally, the big question: what happens if I sync this database with my iPhone? The iPhone app presumably won’t mount the Samba share, so will this mobile version of the database simply never contain file contents?
I’m probably missing something obvious, so thanks in advance for helping me figure this out!
Thanks for your reply. I guess I wasn’t clear what it was that got stored in a dtCloud file on my WebDAV server. Is this database file identical to the database file on my local machine? Or is it in a special format specifically for remote syncing?
I had tried syncing some indexed image files (index of a SMB volume on my Mac), and was surprised to see the image appear on my iPhone, even though the file contents should be empty. Does the meta data include a preview image perhaps?
Sorry, one more question about WebDAV syncing, in reguard to iOS’ on-demand download feature:
Suppose I create a database with an indexed file, pic.jpg, so there’s only a file path and no content (for example: /data/pic.jpg), and then sync that database to my WebDAV server. Next, I sync this database with my iPhone. I can now find this “empty” pic.jpg file on my device, and of course, tapping “Download” will not work. But WHAT IF the file path happened to ALSO exist on the WebDAV server (/data/pic.jpg happens to exist)…?
Will DEVONthink on the WebDAV server check the file system for indexed files like it checks the file system for indexed files on my Mac?
It’s a completely different format optimized for synchronizing.
Indexed contents are synchronized as long as the option “Synchronize contents of indexed items” isn’t disabled. In addition, the indexed volume should be mounted during synchronization, otherwise the contents can’t be synchronized
This helps—I hadn’t noticed that setting! It was checked, but I think the sync to my (remote) WebDAV server failed/didn’t finish on account of the large size of the (local) Samba share I was attempting over the Internet (+15 GB). I had incorrectly assumed it was only sending meta data to my WebDAV location.
I tested again, indexing a much smaller folder, and this time the on-demand downloading worked. This makes sense to me now that I understand the sync locations receive all file content, thanks!
I think I have a solution that’s working for me now:
Even though I only have one WebDAV server, I’ve created TWO Sync Locations with the same credentials: Inbox.dtCloud and Index.dtCloud. Index.dtCloud has the option “Synchronize content of indexed items” UNCHECKED. Now, any databases on my Mac I want fully available on my iOS device, I include with Inbox.dtCloud. And any databases that are indexes of gigabytes of externally mounted network storage, I include with Index.dtCloud.
This keeps my WebDAV server happy and allows me to search my indexed NAS—even though the file is unavailable on my iOS device. At least, I can copy the item link of a found item and use it on my Mac’s copy of DevonTHINK.
I think DevonTHINK To Go would be better off NOT showing the “Download” link on an item when it’s not available in the dtCloud—that was confusing for me. The item link IS handy, but it would also be handy to have the original path to the file on the file system. That way, I could copy and paste that path into Transmit (after connecting to my NAS) and access the file directly.