Dropbox is pushing to migrate to Apple's File Provider on MacOS

DEVONthink
1

Don’t know when or whether this push becomes a new reality, but it does pose some questions. The list of expected changes and known limitations can be found here.

Major issues / questions / requests

  1. Does it change something for those who are syncing via the Dropbox?
  2. The need for a kind of “Smart Deconsolidation”
  3. …

Let me leave this list unfinished (ready to update the OP if you find other important questions). First one is for our respected dev team, but for now I’m interested in a kind of “Smart Deconsolidation”. And it is not only because of the Dropbox.

Issue No1

Some problems and good solutions may be found here, thanks to @cgrunenberg. But new issues still emerge (see the link above).

BTW, due to Apple’s limitations with File Provider, it may be a good practice to make in (whatever crookedly Apple will name the Dropbox folder) the folder Dropbox and do everything in this folder.

Issue No 2

May be this is just my problem, but when I work with the indexed files, I use very actively the function to “Move into Database” and “Move to External Folder”. This is a very nice feature, which makes possible:

  • kind of snapshots of some files with collective access (you just duplicate it and move into DB - so, you have the local exclusive copy, not accessible by the others)
  • you just want to hide/show some files to other participants of shared indexed folder
  • you need some materials in shared cloud (Dropbox e.g.) indexed DT Group which are private.

So, sooner or later, you end up having a massive set of different indexed folders with different indexed status of included files and folders. Moreover, you work intensively with custom metadata, and straight re-indexing will kill them all (not to tell about the mess with the reps of reindexed records). Then, not very suddenly, you understand that you need to move to other location (like moving the whole Dropbox folder to ~/Library/CloudStorage)…

Possible solutions

The easiest way - If you do this moving yourself (unlike Dropbox case).
I think you just may use the script to change the path property of indexed record, but I didn’t manage to make it work (file is just reindexing at the old place):

tell application id "DNtp"
	set theRecord to item 1 of (get selection)
	set theNewPath to "Some new existing path nearby"
	set the path of theRecord to theNewPath
	synchronize record (item 1 of parents of theRecord)
end tell

I guess move function may be the right way

Dropbox case
(moving is a part of some other process you don’t control or even is done automatically/unintended)
There may be needed 2 scripts, and this solution seems to me as more stable:

  1. “Smart Consolidate”
  • writes indexed property to some custom metadata field
  • consolidates
  1. “Smart Deconsolidate”
  • location chooser
  • if custom metadata ‘indexed’ is true then deconsolidate record theRecord to newLocation

I think this way you will save your custom metadata, no need to mess with hidden preference of auto deconsolidating, and restore the indexed/not indexed status. Between these scripts you may manually review and decide if you want to leave this or that file indexed.
And a smart rule probably, which is run on a timely basis syncing the CMD field with actual indexed status meaning CMD is right in the conflict.

Other solutions?

2

This location is actually the new one since Ventura, see WARNING - if you index files, BE CAREFUL with how you install new Dropbox + Mac OS [edited!]

3

PS, regarding indexed files in a new location…

4

Thanks Jim, but I’m talking about hundreds of files, I think script here is a better bet for it.

BTW, if I do this with indexed DT group, which has indexed and non indexed file and update, I will get two same indexed groups: one with indexed file, other - with non indexed. And at the same location. Group doesn’t move to the new location…

5

And one more important question about indexed files, where the corresponding file was somehow moved or deleted.
The problem is that I have very valuable info in custom meta data fields, and I’d like to save it, and also the UUID, and unique set of reps it has (reindexing brakes it all). Is there a possibility (hidden option) to not delete it automatically (even if it can’t find the file on disk), in order to have time to save it all, find it, change the path to normal etc?
Now, if I reopen such a group or hit File > Update Indexed Items it disappears to nowhere. Can’t find it even in trash.

6

Thanks Jim, but I’m talking about hundreds of files, I think script here is a better bet for it.

You update the path of the indexed parent group, not individual files (unless you’ve indexed files individually)

BTW, if I do this with indexed DT group, which has indexed and non indexed file and update, I will get two same indexed groups: one with indexed file, other - with non indexed. And at the same location. Group doesn’t move to the new location…

A non-indexed group isn’t intended to move to a new location. Internal groups don’t exist in the filesystem so there’s technically nothing to move.

7

You may try to reproduce it:

  • 2 indexed groups: first and second
  • inside the first group there are 2 files: one is indexed, other is not. Second group is empty
  • change location of the first group to place it inside the second group (by the method you described - via inspector)

Result:

  • in DT: 2 identical duplicated first groups, inside one of them indexed file, in other - non indexed, second group is still empty.
  • in filesystem: one first folder with indexed file and empty second folder
8

How do you get a non-indexed file in an indexed group? And why?

9

Right-click - Move into database
See in the problem statement of Issue No2: if you work with indexed shared folder: local snapshots of docs, showing/hiding files in shared folder for multiple reasons (means when you move the file in indexed shared folder into DB, you hide the file from the rest of the users of this folder).

10

It’s a fascinating question from the standpoint of understanding computing and Devonthink.

But as a practical matter it seems to me combining indexing, critical custom metadata, and shared files in this way is ultimately a vulnerable system - for all the reasons you describe well.

Might it be more robust and reliable to do everything in Devonthink (not indexed) and set up different databases with different user privileges depending on what you want to share and what you want to be private?

2 Likes
11

How would you do that with DT if it’s not the server edition? Anyway, I agree with everything else you said – this setup is a very complicated way to shoot yourself in the foot.

1 Like
12

You know, it’s not that bad as it may seem. Let’s see a brief use case.

I have dozens of students, from bachelor’s and their course works to PhD with their theses. Each of them has a folder under his/her name in appropriate Dropbox folder structure with all the needed sharing rights properly set up (some of them on OneDrive, but it doesn’t matter right now).
They work in these folders and the work is synced automatically. At any time I can come and see what’s going on. But to assess the work I do it when they ask (via Dropbox chat).
All this Dropbox folder structure is indexed in DT inbox of my work DB. I track the progress on each file using a set of custom metadata (type, stage, group, mark, review date, text field for comments on progress and etc).

All this works just fine, minimum of time waste and redundant transactions, last version is always at hand, students are happy, because they can make urgent edits instantly and right on the go, even on mobile phone.
But.
There is always a one per dozen, who never hear what you say. Notwithstanding how many times you said it, he download the file make edits and upload it back, deleting the previous version… So, when you come to his folder you see a new file, all custom metadata are gone with all the relevant info.

I have a script to move all metadata from one file to another, but I need a chance to catch it before it is auto deleted from DT.

2 Likes
13

That’s a very interesting arrangement. I suspect you are pushing the limits of DT to use it collaboratively with students in such a widespread fashion.

I might suggest 3 alternatives:

(1) How about using Google Sheets - you can assign a Google Sheet private to each student and then make each of those a tab in your teacher’s master Google Sheet. You can then add links for the Dropbox files to Google Sheets and keep the metadata in Google Sheets

(2) Dropbox suports “custom file properties” which is basically custom metadata. But it does not work through its UI; you need to use its API and/or API Explorer to do that.

You could use these Dropbox custom properties either with your current DT system (without the fear of losing the metadata via an indexing problem) or with Google Sheets.

(3) If a paid app is a possibility, you could use Monday.com - only 1 user is needed for you as the teacher; the students could each have free guest accounts as long as their email domains do not match the domain of the monday.com account. Monday.com is set up as its primary mission to do exactly the kind of collaboration of files and metadata that you are doing.

1 Like
14

You could do that by having each user sync to a local DT copy.

But I suggested that before I realized it’s a large class of students; I agree it’s not feasible to do it in that case.

1 Like
15

Thank you for sharing alternatives, Dropbox custom file properties is an interesting solution, but I tend to keep it all in my work database, moreover I use other cloud services as well along this way.

I’m quite happy with the workflow described and DT. This issue arose due to this development in Dropbox. And now I need a kind of “smart decosolidation” if Dropbox decide finally to move all the users to Apple’s File Provider. I know that Dropbox have been doing it since Ventura, but I always refused to transfer to File Provider.

I think may be @cgrunenberg will give me a hint of how to save DT item, which lost its file. Or not auto-delete it until I fix the problem or at least save metadata.

1 Like
16

What a good use case for git / GitHub issues and projects - and LaTeX…