Moving to a new usage style

Hi there!

In the past I used to import all my stuff into the DT database – meaning that I created a copy of every file inside the database. This lead me to the considerable and somewhat frightening database folder size of proud 1.79 GB! So I started to consider just indexing the data and leaving the files outside of the DT database.

Is there anybody out there who share some experience on how “stable” DT is when used this way? Are there problems with broken links?

And most important:
How can I synchronize my DT database and the files on my HD? The problem is, that some of the files on my HD are already in DT, but some are not… as well as some of the file in DT aren’t in my HD file system yet.
Is there an efficient way to get this done?

Best regards
Christian
(I hope I explained the problem clear enough… :confused: )

I’m still using it that way, except for some large document collections (e.g. Tiger Reference Library) that are external and indexed.

The possibility of broken links is one reason I prefer storing nearly everything in the database. That also makes it more portable when transferring it between different systems that don’t necessary have the same filesystem hierarchy, which became an issue for me now that I have three Macs.

AFAIK it can’t be fully automated (yet); see dr_tone’s post in Automatic syncing not exactly like anticipated for his take on that. Syncing issues were another reason I decided it would be easiest keeping the database primarily a “standalone” entity for now.

A big reason I use DT is because I can easily store and find information in it without much concern for location, even if its group/item structure is analogous to folders/files hierarchies. I’m hoping DT eventually makes it possible to detach further from hierarchical organization, maybe with some “mind mapping” capabilities? I tend to have a lot of distinct “projects” that are sometimes related, but not hierarchically, and choosing where data “belongs” can be tedious. The relationship matters more than the location.

Definitely. And I think this topic really deserves to be a FAQ by now. :slight_smile:

Christian:

Sjk has responded to your other questions.

I’ve been using DEVONthink for more than 2 years. When I started, I couldn’t be certain how stable the database would be, or whether it would continue to be supported. So I opted to keep my many PDF reference files outside the database, and to import them to DT as linked files – I also have that preference checked for unknown file types, Quicktime files and images.

If I had opted to import these files into the DT database Files folder, my Files folder would be larger than yours…

First, let me answer your query about the stability of my database with linked files. I’ve had no problems whatsoever with broken links. But that’s a qualified answer. At some point, I’m going to want to move my DT databases to a new computer. That’s when problems will emerge because of the options that I chose early on. I’ve got my TiBook 60 GB drive partitioned into three volumes, and my linked files are contained in two of those three volumes. That means that I will need to partition my new computer’s hard drive with the same three volume names to make the migration go smoothly, and will have to copy the folders containing linked files to the appropriate volumes, or links will break. That’s a VERY SIGNIFICANT DOWNSIDE to the import choices I made in the beginning, and have continued.

Knowing what I know now about DEVONthink’s robustness and continuing development, I would make the choice you’ve made: import those external files into the DT database Files folder. They are very secure there, and you will have no problems with migrating your database to another computer. (But I still would not recommend importing PDFs, images and Quicktime files directly into the database, as a database file could become corrupted, with possible loss of those files.) Even if your database were to become corrupted, it would be extremely unlikely that files in the database Files folder would be corrupted – unless you have a major HD corruption problem.

Be happy. You’ve made the right choice. The only downside is that storing archived backups on an external drive means that your database folder copies will take more drive space. That’s really not a big deal, these days.

As for me, I’m hoping that DEVONtechnologies will come up with a routine (perhaps a script in DEVONthink Pro) that will let me reconfigure my database to move all linked files into the DT Files folder. That will simplify my life when I ultimately move the database to a new computer. :slight_smile:

I agree. My interests center around environmental issues, but necessarily spill over into biosciences, toxicology, health, sustainability, economics, physics, chemistry, statistics and a host of related topics. Designing and maintaining hierarchical organization is increasingly a pain.

I’m capturing new content into DT MUCH faster than I can classify it, even with the aid of the Classify button. (Auto-classify doesn’t work well for me.) So I’m capturing everything in to my Edit This group and falling way behind. Right now that group contains almost 1,900 items! I even tried the experiment of exporting this group and importing it into a new DEVONthink Pro database and asking DT Pro to automatically group related information. Unfortunately, DT Pro was able to group only about 400+ items, leaving about 1,400 items still ungrouped.

Fortunately, DEVONthink’s ability to discern relationships between items seems to work well, even with sloppy hierarchical organization of contents. The See Also button still does it’s magic, as do Keyword searches. In DEVONthink Pro betas I’m making good use of smart folders to pull relationships together (and still wishing for the Boolean search capabilities of DEVONagent to make it into DEVONthink).

Of course, the more demands we make on artificial intelligence capabilities in DEVONthink, the more we encounter bottlenecks in CPU power and speed in existing Macs. I wonder where we’ll be 5 or 10 years from now? :smiley:

I save PDFs and images directly in the database since I only keep a limited number of them in it right now. And additions/changes are infrequent enough that I’d be likely to have them on a backup. If I were to upscale the volume (a long procrastinated task) I’d switch to copying them to the database Files folder, like Bill and other forum members do and have recommended. I’d still like that Files folder to have a few subfolders, maybe grouped by item type.

Same here. And too many items belong in multiple groups, which I used to replicate to different groups more often but now that seems less important and too time-consuming to upkeep.

I’ve only just started with DT today–I’m trying it out after having used StickyBrain for a few years.
I began with my PDF & PS Preferences set to “Link to originals.” After experimenting for a few hours and upon reading several messages on this board, I think it makes more sense for me to instead choose “Copy files to database folder.”

Is there an easy way to take those already imported and linked PDFs and automatically move them into the database folder? While I’m asking, it would be most convenient if there is an option to delete the original file, too.

Thanks.
Mark

OS X (10.3.6)
DT 1.9a

No, there is no special command or such for doing this. What you could do is export everything, delete all DEVONtech_storage files and then import it again. This should import everything with the new settings.

Best,

Eric.

Thank you, Eric.
I found one DEVONtech_storage file in each exported folder and deleted it and, of course, the import worked fine. Some of those imported files came in as dark blue–I gather that indicates a wiki link which I’m still trying to understand, especially how to jump to that link–and others were dark red. I haven’t figured those out yet. I’ve only been able to spend a few hours examining DT and these forums, but I find the program very intriguing.

Mark

Perfect.

Blue = Duplicates
Red = Replicants, documents file in more than one place

Best regards,

Eric.