Has Devonthink added a way to move indexed files between groups yet?
You can already move indexed files between groups in DEVONthink.
However, it is still not a filesystem, so it’s not going to move files between indexed folders in the Finder unless you brought the indexed file into the database, moved it to the other indexed group, then moved it to the external folder.
Your suggestion about ingesting moving, and exporting seems very convoluted for a tool like Devonthink which is designed to make research and gathering information easier. Why not just make those steps invisible to the user and just “make it happen”.
I live with a lot of data and research on my NAS/personal cloud because I use an Apple Macbook air with a smaller SSD. Therefore, I cannot import all of my research data locally to a 128gb SSD. Moreover, if you need a document path/link to work outside of Devonthink, say in Scrivener and Endnote, you cannot link a file that is imported into Devonthink. It breaks as soon as you open it on another Mac (My office Computer) or PC or if you open it in a windows version of either Scrivener and Endnote.
I understand its not a file system, however, I do think that moving a file externally from within Devonthink is a requirement. think its a pretty important feature for information management product to have.
Don’t get me wrong I love Devonthink, but when I’m arranging my information for projects, I want my newly ingested data to match my filesystem. I use an “Inbox” on my NAS for information that is gathered or dropped there by an assistant. I then want it to be indexed and then I can start the process of analysis and begin to decide its classification, tagging and finally its final resting place. None of these steps requires Devonthink to be a “file system”
People make it sound as if the current way of DT handling this is essentially a bug, a or shortcoming. I think this is much, much trickier than many make this out to be. In a nutshell, I would say that one “master” has to be in charge. If the file is inside DT, then DT is the master. If you index, the filesystem is the master and DT only follows. Once DT and OS X are both allowed/permitted to move around the files, there will be complications. Imagine you are using more than one information management program. For example, I have such a setup. I have a large BibDesk/BibTeX database of scientific papers. Pdf versions of the papers are auto-filed by BibDesk. To have access to these papers from my general science database and also in DTTG on iOS devices, all this is indexed into DT. Nothing from within DT must be allowed to move any of these items, otherwise the BibDesk system will be broken.
This synchronized moving might fit the usage pattern that you are following right now, but I suspect that as a globally consistent method, it would be difficult or impossbile to implement.
I think there is a reason why “information management products” generally move everything into their own DB/folder hierarchy, which you are not supposed to mess with via the Finder. Indexing is a fragile business; essentially, in terms of DB integrity, it’s asking for trouble. As such, it should only be used in cases where it is utterly unavoidable.
I agree that it shouldn’t be seen as a bug or shortcoming. It makes a lot of sense to me, and it sets DT apart from other apps.
In my workflow, it really helps a lot to have the indexed items move around in Finder as well, so I think an option to “turn on” such a feature would be nice, but that would be an additional function or option to add, not a replacement of the current one. In other words, I think we ought to support multiple workflows, if at all possible.
I can see that in a setting where one works essentially purely with indexed folders, this could make sense. However, I see issues that have to do with the fact that group structures (and indexed folders are part of that) in DT are not 1:1 equivalent to the OS X filesystem:
-
Moving and copying is OK. As far as I can see, it works identically in both systems. And that’s what this thread is about. So yes, DT could be re-programmed to execute any move/copy operation inside DT on the corresponding indexed filesystem folders.
-
BUT: Replicants have no direct equivalent in the filesystem. Aliases come close but are not the same. So what happens in your scheme when you replicate a file from one indexed folder to another one? I just checked what DT does in its current implementation: As I would expect, nothing happens on the filesystem side. At that moment, the exact correspondence between DT group structure and the filesystem in broken for good. It might depend on the workflow, but at least for me, replicants are the most useful, powerful feature, that distinguishes DT from just being “a better filesystem”. They reflect the advantages of “tags” over “folders”.
How would you propose to fix that? By having DT produce an OS X alias in the filesystem when DT gets a replicant in an indexed folder? But even that’s not the same. An alias is different from an original, there is an asymmetry; the alias can point back to the original, but the orignal cannot tell you if and where aliases exist. Replicants are truly one and the same. As far as I can tell, this cannot be resolved in a fashion that makes the DT and the filesystem structure completely equivalent.
Upshot: At this point I believe that demanding or trying to create an exact equivalence between DT and filesystem structures is a pipe dream. You can get away with it, if you restrict yourself to moving and copying, but not when replicating. The latter is a prominent feature of DT.
I encourage anyone to correct me where I’m wrong.
A remark on the side: This issue with replicants is in my view the biggest problem that arises when you try to export a DT DB into a filesystem structure. It does not work properly. Because all the replicants are exported in their respective groups as original files. I.e. if you had on the DT side a file “myfile.pdf” replicated into 10 groups, then the DT export feature will copy 10 identical, but independent files into the 10 folders that correspond to the original DT groups. Apart from the potentially annoying, but purely technical issue of a massive increase of used disk space, the real problem is that the logical connection between these instances is broken for good. If you annotate or edit one of these files after the export, the other 9 instances will obviously not be updated, turning this into a useless exercise. So exporting has to be done in a different way that does not rely on the filesystem structure mirroring DT groups, but rather by using OS X or OpenMeta tags carrying over the group structure info from DT. But there are issues there as well due to the fact that in its hierarchical group structure, there can many groups of the same name, which would get projected onto the same single flat tag in OS X or OpenMeta, so one has to be careful (i.e. only use unique group names in DT). Someday, I want to write this up and start a thread.
I index over 95% of my documents and I agree with your assessment. Additionally, I see another significant downside of attempting to match the database structure with the filesystem structure. If DEVONthink were to automatically move documents in the filesystem, then the ability to organize documents in the database with a grouping other than one matching the filesystem is lost. I like the ability to have a single group in DEVONthink that may contain indexed documents from multiple locations in the filesystem, as well as documents imported into the database. Automatically matching the filesystem to the database organization would completely break this.
hi. i don’t know if you are right or wrong, because i lack the experience or the know-how to evaluate whether such a thing is possible. however, if it is, i would like to have the option to more closely reflect the finder file structure in devonthink. i regularly use replicants as well, and i think they are a fabulous feature, so i certainly wouldn’t want to give them up to achieve this. you raise some interesting issues, but i’ll have to leave it to the dt folks to figure out whether this pipe dream can be realized.
Exactly! Once you start chaining yourself to a strict 1:1 correspondence, you wonder what that is actually good for. If we forego all the advantages of the DT-specific features (in other words, largely replicants), then I would simply do all the organizing (i.e. filing, moving, copying) in OS X, and then simply index that whole OS X directory tree into DT to use it for its superior search and analysis (and for syncing all the material to DTTG), but would refrain from any organizational activities from within DT.
That way, I will also be able to do this with one or more additional programs (BibDesk etc). They can then all share the common material without any interference. As stated earlier, I firmly believe that there needs to be “one master”.