I have an indexed group with several subgroups (or folders) and want to rearrange some documents into other groups inside that structure, i.e. move files to different folders. Now I have two possibilities:
Move the documents in the file system (for example with Finder) and synchronize. But then Devonthink will forget all its information about that document (like label, URL), because it believes the file in the old group has been deleted and a new file created.
Move the document with Devonthink. But this operation is not reflected in the folder structure on the hard drive, i.e. the file stays in the same folder as before. Only Devonthink then knows about the new location of the document.
A workaround is to import the file into Devonthink, move it and export it again in the new location. This will work but is cumbersome and easy to forget. And if I forgot and just moved a document, which then is in the new DT group but still inside the old folder, I might never realize this until I explicitly search for that particular file.
I tested this in 2.0.9 and it works: two indexed folders, A and B. Document XYZ in folder A. Labled red. Select XYZ and use Move into Database command. Move XYZ to folder B. Select XYZ again and use Move to External Folder. The documents are now rearranged in their Finder folders correctly and retain the labels in DT.
A little less cumbersome than the method @alexo mentions. To ease the effort, this workflow could be scripted with the new consolidate/deconsolidate commands in the DT dictionary.
Thanks, that’s already better than importing/exporting. But I see the problem that every time I move a document in DT to another folder, I will have to pay attention if I am in an imported or an indexed part of the database. Drag & drop works in the first case but will lead to inconsistency with the file system in the second case.
This is not too hard to do for me, because I have just a few separate top groups with all their content indexed. Still, I would prefer a more automatic solution. For example, is it possible to invoke a script when a “move document” is issued, which would replace the move with “move into DB+move+move out”? Maybe attach this script to the top level indexed folder?
Another idea: is it possible to find these inconsistencies, like a smart group which lists all indexed documents which are in different location in DT and the file system? I could then regularly check if the file system is still in sync with the database or if I accidentally drag-drop-moved something.
Yes, but it’s easy to overlook and the move procedure is still a little pain:
move a document to database
drag it to destination group
go to this group
find the moved document there
move it to external folder
go back to previous group
… in comparison to a simple drag & drop. It might work for single document, but I wouldn’t want to sort a medium-sized collection that way.
I read up a little about DT AppleScript to automate the move command. I think I can do all the steps for the move itself, but how can I attach the script so that it will be triggered when a move command is issued?
I’ve been struggling for a few days with that issue, have not found yet an acceptable solution. What I want to achieve is to organize (lots of) documents in an indexed folder structure, i.e. work with them like I can with imported files. Apart from manual move operations (like drag and drop), the group, auto-group or classify features lead to the same inconsistencies.
Another (desperate?) idea I had was to move the whole folder structure into the database, organize it there, and then move it back. The problem I encountered was that “move into database” works as expected - but “move to file system” is not recursive, i.e. only one folder and its direct children will be moved to the file system. Inside these children, however, the groups and documents are still imported. So I can’t use this. Is the AppleScript deconsolidate command recursive or is it the same?
Any other suggestions? I think I’m stuck here. What’s the point of indexed documents if they can’t be moved any more?
Scripts can be attached to groups and triggered when the group is selected (see the Synchronize script in the Example folder for the method). But scripts cannot be triggered by commands such as “move”. Rather, the method would be to use your script to do the moving and trigger the script with a keyboard shortcut, or from the scripts menu.
For indexed documents, it’s assumed that the folders and their contents are managed external to DT and then the user updates DT with the result (i.e., synchronizes). For imported documents, it’s assumed that the folders and contents are managed internal to DT, and then the user occasionally (optionally) updates Finder with the results (i.e., export).
Perhaps, to mix the two methods opens the door to a wide field of actions and combinations that don’t have an easy solution - or clear requirements that all users agree on. It’s not just moving that needs to be accounted for in a two-way sync, but replication, duplication, tagging/not tagging, labeling/not labeling, renaming, appending suffixes and prefixes, comments, including in synchronization/excluding from synchronization, locking/unlocking from deletion, etc. etc. Ugh.
That’s a possibility, but then the user has to be aware that DT will forget all internal information of every moved or renamed document (e.g. links to it, scripts, annotations, labels, URLs etc.). Even worse: renaming folders.
Still, I will probably do it that way. This should work if I restrict document information to Spotlight comments and Openmeta tags and don’t use any of DT’s special features.
Having a database consisting exclusively of indexed folders and documents would be an option but doesn’t change anything in this respect, or does it?
I think a read a bit about importing vs. indexing, but never heard about these huge disadvantages of indexing. Am I the first one who’s actually trying these things?
It might be helpful to know why you need to index documents, and also why you need to be moving the in the Finder on an ongoing basis? Not saying this is a bad thing, but it could be helpful in offering a solution.
I use indexed databases exclusively now and I do not find DEVONthink’s behavior limiting at all, now that it has the move in/out of the database command. But then again I don’t have a need to move documents in the filesystem once they are in the database, nor do I particularly care if documents remain in one folder in the Finder after I move the document in the database. I have two needs for indexed databases-first, to index dynamic folders such as podcast folders in the iTunes folder. This could be done in a mixed database, so the main reason I have indexed the entire databases is so that I can tag search with Punakea. If (when?) DEVONthink offers more robust tag searching, I probably re-import the documents to the database.
I don’t necessarily need to move in the Finder, but as I described earlier, if I move indexed documents with DT, these moves are not reflected in the file system. I index some folders/files because I want to use them with other applications, too. This can be important for a variety of reasons, cooperative work being an important one. Without a directory structure, even I can’t locate my documents outside of DT.
I have a “living” directory structure, meaning that I change it constantly as new research topics emerge. Only moving within DT and leaving the files in their first folder would leave a mess after a few weeks. To give you an example: I may research a very special subject. For many years, until last week, I had one group for “file systems” (ironically!), now this group has seven subgroups. The opposite can happen, too: topics slowly die, once promising research outdates or is refuted.
It would be much easier if my interest was 20th century Portuguese literature or something like that .
So I want to use some documents with other applications, but the structure is ever changing. I currently see no better alternative than organizing my collection in the file system and then synchronize with DT.
I have always seen the “Move to External” command available on imported items, so I’m not sure if I get the point here?
But thanks for that script! It was a great sample (very useful because I have no idea of AppleScript). I changed the export command to desconsolidate and made it work recursively on children, deconsolidating anything that is not indexed on the way. I don’t trust it yet entirely, but it’s a start and works so far.
As an extension: As it traverses through the document tree, the script could discover documents which are in different groups in DT than folders in the file system. It could then consolidate-deconsolidate such documents, thereby moving them to the correct folder in the file system.
But I’m not sure how to check this. The “location” and “path” of a record seem to provide the required information, but I would have to do some string manipulation to compare them.
.