Database: Indexing / Importing / Exporting with Cryptomator

DEVONthink
1

I have some content in a Cryptomator Volume (which means, the content is encrypted until I open the vault).

This Volume is then usable as /Volumes/CRYPTOMATOR in macOS.

If I just import this folder into DT, DT does not get updates to the volume and the volumes does not get updates from DT. This would be pointless.

Therefor, I was thinking about indexing this instead:

When I index this folder, I can add, change and delete things from DT and they get reflected in the volume - and vice versa.

Right?

I could even add this database to the remotely synced databases and could access the content from DTTG.

Right?

What, if I then add or change or delete things from DTTG?
The change would get noticed from DT when I start it again and therefor, the changes again would get reflected in the Cryptomator Volume.

Right?

I just have massive respect for indexing databases and fear that I may do something wrong and loose data … :smiley:

2

We don’t use Cryptomator here so you’d have to test it in your environment. It may… or may not… issue filesystem events that DEVONthink would be aware of.

I could even add this database to the remotely synced databases and could access the content from DTTG.

No, DEVONthink To Go wouldn’t be accessing the remote content on another device. It would have a ocal copy of the data on the iOS device.

What, if I then add or change or delete things from DTTG?
The change would get noticed from DT when I start it again and therefor, the changes again would get reflected in the Cryptomator Volume.

Yes, changes would be synced between DEVONthink To Go and DEVONthink. Technically it would appear the indexed folder would be updated but again, you have to test this in your scenario.

I just have massive respect for indexing databases and fear that I may do something wrong and loose data

Good! People shouldn’t fear indexing but be thoughtful and understand the filesystem ramifications when dealing with indexed items in DEVONthink.

3

Many thanks, @BLUEFROG

Any DT / DTTG user who already did something like this?

This way, I could access content within a terminal shell …

And also, I still could access this content when either DT, DTTG or Cryptomator would not be available for some reason or in some situation.

Seems like a win-win situation …
In some initial tests, this seems to work.

4

From where… and why?

And I don’t know of any other Cryptomator users offhand.

5

Just on the Mac.
Open a terminal shell, issue “cd /Volumes/CRYPTOMATOR” and then do things with shell commands …

6

Like… ?

7

Not sure what to answer here :wink:

I work all day on the command shell.

Run “sed” and “awk” to analyse and extract data, move and sort files, rename stuff, write scripts …
And so on.

That’s my work.

8

Well, I’d say your shell commands are unrelated to the topic at hand. You can process the Cryptomator folder in whatever fashion you need to, including shell processing. DEVONthink and DEVONthink To Go operate outside thos actions. however, if you’re moving or deleting indexed files outside the database, you should consider whether indexing is the best idea.

9

I tested this with creating a new folder, renaming another folder, deleting an empty folder and moving some files from one folder to another folder.

All those change done with a bash command line got instantly reflected in the indexed DT database!

So far, this seem to work flawlessly.

Not sure about what actions I would need to be careful.

Thanks a bunch already!

10

I noticed something that does not work, strangely.

I have the Cryptomator volume also available on my iDevices and just duplicated one file.
This got instantly visible within the Cryptomator volume on my Mac, as expected (this is a folder on OneDrive).

But this time, DT did not notice the change … most probably, because it was not issued on the same machine, but remotely.

But after a “Update indexed items” from the DT menu, the file showed up.

So this method seems to be valid.

11

You’re welcome. That is expected behavior when indexing cloud-synced folders. This is discussed in the Help too.