Maybe because I’m not a programmer or a database expert, but this seems to hide some pretty opaque ideas under superficially transparent language.

What, exactly, would it mean for the OS to “properly deal with files,” and what hooks might it provide? And how challenging would it be to provide a general-purpose set of hooks that would be useful for even a large subset of applications?

Or, at the DT level, what would a “proper file structure” even look like? What user need are you trying to serve that DT itself doesn’t meet? (Or that can’t be met by applying Spotlight to the existing structure.)

I don’t mean to be contrary, I just honestly don’t understand what you’re talking about.


Not to mention iTunes and iPhoto! And Scrivener. And…

I think the issue is that self-contained single documents just don’t work anymore. A presentation might have embedded spreadsheets, embedded video, graphics from many different sources, etc. A long word processing document might have a whole raft of reference materials, references to other documents, versioning, embedded objects, and so forth. People have large data collections that they use over and over for different projects. The discrete file approach to managing all of that has, I think, pretty much collapsed under its own weight. People buy Curio, and DT, and Scrivener in part because they offer a better way to manage the components of large projects.

But that means that the relationships between files are as important as the files themselves. To track those relationships, you need a database. (There are also data integrity issues here. If your job is to track relationships, you need to discourage the user from changing those relationships through means that you don’t know about.) And since each program is serving different users, trying to do different things, with different kinds of data, each needs a different data model.

And yes, it’s a mess.


Thanks for the thoughtful reply. I don’t know if I agree with the example of Scrivener. I think it uses a package, not a database. Which is a great example of what I am talking about. What is wrong with the package model? I realize no one wants a Devonthink sized package. But couldn’t a package contain considerable meta data that allowed for references to other files? Maybe I’m talking pie in the sky here, but Apple just announced linked Numbers charts in Pages and Keynote documents. Of course I have no idea how that works, but those are apps that use packages and not DB’s.

Um, a DT (v1.5) database is contained inside a package, too. And I think you would have a very unpleasant experience if you tried to edit an individual Scrivener document outside of the project to which it belonged. (Without first using Scrivener’s export functions, of course.) I don’t have the technical knowledge to argue about exactly what is and isn’t a database, but a Scrivener project is a very different thing than a Pages or Word document containing a linked spreadsheet.

Embedded references to other files have been around for a long time. Word for Windows 2.0 used them in the early 1990s. Packaging up an entire project (Scrivener, Curio) or an entire library (DT) and presenting it as one entity is something different.


I suppose this is the right place to mention this. It seems DT leverages the power of Databases. I am enjoying the speed with which I can locate files and edit them… once they are in the database that is. This is the main reason I am exploring DT but not sure if it is enough to keep using it. There are a couple limitations to the database issue which makes it less than appealing and has me considering “Indexing” versus duplicating documents.

  1. Creating a New File - Unable to Save Directly into DevonThink:
    I can not save a new file created in Word or PowerPoint or another program directly back into Devon. I have to save it in a seperate folder and then copy it to the right Group Folder in Devon. This is a duplication of effort and it would be great if I could save directly to the group in Devon. It adds to processing. I can always create a Rich RTF in Devon and then save it as a Word File but the same issue exists - If I transform the RTF into a Doc it must be brought over.

  2. Mail Attachments
    It is great I can find a file and attach it to an e-mail. The problem exists when I am responding to an e-mail and need to attach a document. I can’t simply “Find” the DT file and attach it because it seems it will be sent in the Devon Format and not the original format (.DOC, PPT etc.) I know there are work arounds but again it slows productivity not to be able to find and attach a document in the database.

Again, I am not sure of the downsides of “INDEXING” Versus “DataBasing” my files but if I am trying to maintain consistency, be able to save so Devon Finds the file, and leverage e-mail better - it seems maybe Indexing is my solution.

Finally - I have updated a lot of files in Devon that are now different from the originals found in Finder… I assume it is wise to create a file structure in Finder that allows for easy export and would automatically overwrite the older files so I can from time to time align the two databases?

Regards - David (Rookie User)

That’s not true. To initiate a new Mail message from within DEVONthink 2 that will contain the desired attachment, e.g., a Word or Powerpoint file, select the document Name (e.g., in Three Panes view) and drag it onto the Mail icon in the Dock. The result will be a new message created in Mail and containing the attachment. Makes no difference whether the document had been Imported or Indexed. The file will be attached.

But you have already started a message, and now wish to attach a DEVONthink document to it? Simply drag the document from the DT database to the Mail icon as above. Once more, a new message will be created, containing that attachment. In the new message, select the attachment and copy it to the clipboard. Paste the clipboard into the message in you wish to include the attachment, and it’s there now. Want to include several attachments in your message? Repeat this procedure.