I have been using DEVONthink Pro Office 2.7.2 on a folder hierarchy that is also accessed through other tools, which is why I indexed this folder hierarchy from DTPO. This has been working very well for over a year now with about 12,000 files and 2GB of disk space.
Last week my MacBook broke down and was replaced by a new machine which has a different hard disk configuration. As a consequence, the path to that folder hierarchy has changed.
Now DTPO does still display the hierarchy and all files due to its index, but I cannot access any of the documents: The window area where the document contents used to be displayed now only contains a note that the file is not present, along with the old path name of the file.
How can I tell DTPO about the new root path of the folder hierarchy?
Apple’s Aperture allows me to “reconnect” images which can no longer be found, DEVONthink should have some function like this, too, but I was not able to find it. Please advise!
Thank you & best regards,
Arndt
PS: When I invoke “File > Update Indexed Items” the whole folder hierarchy is removed from the DTPO database and all my meta data is lost. Ouch!
DEVONthink does not have a “reconnect” feature. You will need to locate the indexed folders on your new disk at the same location(s) relative to the root of the current user.
For example: if you indexed a folder on the old drive at Macintosh HD/Users/Harry/Documents/Important Documents/Projects/Rocket Ships/… then relative to the current user they were located at ~/Documents/Important Documents/Projects/Rocket Ships/ …. They need to be at the place on the new machine. It is OK if the path on the new machine is /Macintosh HD New/Users/New Harry/Documents/Important Documents/Projects/Rocket Ships/… because the root is still the same as far as DEVONthink is concerned (i.e., ~/Documents).
I follow this rule when I move databases between machined. For simplicity, I usually keep documents in a folder located at ~/Documents, or in a Dropbox or Box subfolder because these are always located at ~/Dropbox and ~/Box, respectively.
Thanks a lot for your quick reply, very much appreciated, but in my case the folder hierarchy was on a different hard disk on the old machine (i.e. /Volumes/data/…) that does no longer exist because the new machine only has one hard disk.
If DTPO does not have a means to “reconnect” external (indexed) folder hierarchies yet, then I’d say this is badly needed in order to offer a complete solution.
Are you sure that there is no way to do this inside of DTPO?
Thank you & best regards,
Arndt
[size=85]PS: I know that I could get me an external hard disk just to make the old path names “work again” temporarily, then I could move all files into the DTPO database first and move them out again to a new external destination, which would allow me to save the metadata, but this would be an annoying and time consuming detour considering the number of files, and I would still have to go back and recreate hard and soft links, file and directory permissions, ownerships etc. manually. Heck, I chose to index those files exactly to make sure this directory tree is not tampered with in any way…[/size]
Lightroom has a feature similar to Aperture’s, and I’ve always found it useful. However, on the other hand, it seems to be a rarely requested feature on the forum here, and would be expensive in time and effort to create and test, so perhaps that’s why we haven’t seen it yet.
But now that you’ve restructured your disks, isn’t this unavoidable, regardless of what DEVONthink does?
Well, this is what I will probably have to do for now to get going again.
But what I really want is to persuade the nice people at DEVONtechnologies that they need to add this function to DTPO.
It could possibly be done just as simple as this: The information panel already includes a “path” field (the value displayed here is read-only) with a button labeled "@” which will reveal the respective directory in the Finder or, for a file, open it with the default application. Right now this button appears to do nothing if the path is no longer valid, i.e. in case “the connection has been broken”.
Well — how about opening a file chooser dialog in this case and allowing the user to point DTPO to the new file system location of the respective object?!
korm, are you affiliated with DEVONtechnologies so that you might help me suggest this to them or are you simply a kind soul helping others here in the forums?
I am not affiliated. Staff is on holiday, though this thread (like all threads here) will be read by the developers, noted, and perhaps a staff member will comment.
If you do not have an other possibility (maybe due to space restrictions, or …) you still can use links - so basically you store your dtpo where it is suitable for you and create afterwards a symbolic link at the needed location for DTPO.
So basically this creates directly in your home folder (~) a symbolic link to your database. When you cd ~/neededFoldername it looks exactly as if you were on /Volume/etxDevice/foldername/ and any change you do make in the link is actually made at the original path…
Yes, symbolic links are very useful in general — thank you for suggesting them.
Unfortunately in my case the situation is a bit different since my files used to be in /Volumes/data/some/directory/… and it is /Volumes/data which does no longer exist in the first place. So I would have to create /Volumes/data as a symlink. The /Volumes directory is special however — its contents is maintained by OS X — i.e. one should not mess with it.
I would add my support for the ability to repoint DT to an indexed item that has been moved from its original location. In one of my databases I index quite a lot of large files located on a 1TB secondary internal drive and, as my research project is still at an early stage, I occasionally relocate these files to a more appropriate location, and thus have to delete the broken link and then re-index. The symlink suggestion is very useful, but the ability to do this from within DT itself would be preferable.
I could of course import the files into the database directly, but I have indexed over 20GB of data to this database at the moment, and that total will probably increase several times over by the time I’m done and I’d prefer my boot drive not to be near capacity.
OT, but you might consider multiple databases. A database “several times” larger than 20GB is not likely to perform well and present problems. Monitor your machine’s memory use as the database grows.
Thanks for the advice Korm. As the research project grows, I’ll keep an eye on things and split the db as necessary. Would I be right in guessing that the feature requested by the OP would be even more desirable if a database were split?