Relative paths for indexation

DEVONthink Feedback
1

I did a search and found posts about that subject but nothing about the whys and the why not yet.

  • Let’s say I create a database /Users/~/Documents/foo/bar.dtBase2
  • Let’s say I have bar.dtBase2 index the files in /Users/~/Documents/foo/files

I would like to move the database and the indexed files in another volume. I can’t (well, not easily it seems) simply move everything from /Users/~/Documents/foo to another volume. If I do that and try to open bar.dtBase2 from the other volume (and have the old files deleted), DT will complain about the files missing because the absolute paths would be wrong.

This is the #1 reason why I can’t use indexation. I would love to use indexation.

Is this something that is being worked on? Is there already a viable solution?

Thanks.

2

Paths are either relative to the user’s account, to the startup volume or absolute. But they’re not relative to the database, meaning that you can easily move/copy the database to another volume (the most common task) but you can’t move the files without breaking the references.

3

@cgrunenberg thanks for the clarifications.

I also took note that if I create a symlink from my local user file system to another Volume (e.g. /Users/~/Documents/link->/Volume/Research/files) that the symlink is resolved once the indexation is done (DT will show the absolute path from /Volume…). It seems there is really no way at all to move the files from where they were.

I am curious ; why no option to have the files be indexed relative to the DB?

Thanks!

4

Well, you’re the first one requesting this :wink:

5

hey pdurocher,

just for fedback and general support: it seems an important question for everyone who is systematically using indexation and wants some sustainable data management with dtpo. of course you can reindex everything when moving files, but its clear this doesn´t help when you use replicated files etc.
so in this regard your enquiry makes sense for everybody following the given and offered index-option.

6

I regularly move databases and documents indexed in those databases en masse from one machine to another.

Structure:

~/Documents/Workfiles
~/Documents/Workfiles/Project Data/… [subfolders]
~/Documents/Workfiles/Databases

The documents that get indexed go into the subfolders of Project Data. I index Project Data.

Using ChronoSync to sync the ~/Documents/Workfiles structure between machines.

@pdurocher - is this what you’re wanting to do?

7

fyi:

same issue: http://www.devon-technologies.com/scripts/userforum/viewtopic.php?f=3&t=10751&p=51145#p51145

8

Christian, if this might help increasing the weight of the feature request, I’m another one who would find relative indexation a need. Maybe it’s bad habit, but it happens everyday, to me, to change the placement of indexed files in the Finder (while the database is growing, different structuring of my research folders are needed).

Others have suggested me workarounds, but they resulted all but immediate and error proof.

So, if adding indexation relative to the database is only a matter of choice, I would say: add it. Someone, here, would be very happy you did.

Paolo

9

+1
– especially if this means that automatic indexation with the synchronize.scrpt will work on all my machines when both my database and the indexed folders are kept in sync by dropbox. Currently, the automatic indexation works only on the machine on which it was set up.