Index an alias?

I’ve successfully indexed a group of nested folders into my family history database in DtPO. The resultant DtPO groups were set-up quickly, and the contents were was spot on with one notable exception. No documents represented by aliases in the source folders appeared in the indexed groups.

I probably shouldn’t be surprised – that’s a lot of chasing links to find an original document. Since I don’t understand what goes on under the covers with aliases, there’s doubtless a good reason my grand scheme didn’t work.

Am I correct that one can’t index an alias? Is there a workaround that might let me continue with this intended structure?

Thanks for any input.


Yes. If you index an alias (or a symlink), what you get is an index of the original.

Change the structure – or Index the original? Or if you need multiple instances of a document, index the original and then make replicants in the database. Or just important the whole thing and make replicants in the database as needed.

1 Like

Thanks, Korm, for your reply. If you’ll give me one more shot, I’ll do my best to stay out of the weeds.

In Finder, I have a system of nested folders. The top level is 150 folders – each one for a unique surname. Most of those top level folders have a dozen or so subfolders each containing documents and images for an individual having that surname. Before discovering Dt, I used this structure, in Finder, as my filing system for digital research products. I would like to maintain the same structure, now as groups, in Dt where the horsepower and flexibility continue to amaze me.

In the former system, these individual’s folders often contain a number of photographic images – each as an alias of an original image in a repository. Example: I have one photo in my research of a family and wish to put “a copy” of this family photo into the folders for each of the persons in the photo. The original image is in a repository (in my Pictures directory) outside the nested folder structure. Placing an alias of that family photo into each person’s folder has worked well and supported my work.

While I’ve moved my research workbench to DtPO, I want to keep that repository as is since my ultimate destination for the originals is Reunion – the genealogy application where I assemble the results of my research into a family history which includes as many photos and images as possible. The ease of linking the images out of that repository into Reunion is a significant driver.

As noted, I have indexed that entire nested folder structure into DtPO. In every individual’s group in Dt, all the contents were indexed and showed up (as expected) except any image in that indexed folder that was an alias was absent.

Given this wish to keep the repository in my Pictures directory, do you see a possible solution? If I abandon the index approach, I can certainly make this work, but I want to be sure before I rebuild what’s worked well in the past.

Thanks for your patience and also to anyone else with an idea on this.


It’s a tough one. I don’t see much of a way around this: the dependence on aliasing in the structure you’ve built in the file system can be also be implemented in DEVONthink – but it means recreating the photo repository and placing replicants into DEVONthink groups as a replacement for the aliases that will not index or import. You can have it one way (in the file system) or the other way (in DEVONthink) but not both ways.

There are utilities available to replace aliases with copies of files (AliasHerder, or the “rsync” command, for example – there are more). But then you would have a lot of copies of files and no link back to your photo repository.

Other than a requirement to keep all photos in the same repository – is there a case where you update the photo and want those changes to appear instantly in all the folders where you have aliases of the now-changed photo?

Here’s a quick and simple example of what can be done inside DEVONthink…

This doesn’t address your current scenario but is just a small proof-of-concept of how this “aliasing” could be accomplished via the Replicants korm mentioned.

The way Reunion handles multimedia is to my mind is the biggest shortcoming of Reunion which otherwise is still the best, imho, genealogy software for the Mac out there. If you move either intentionally or accidentally the images, the link between them and Reunion has gone, I have been caught out more than once in this way! My preferred way is to put all my images into the person’s Group in DTP and then drag & drop them onto the person’s card in Reunion. It does not solve the problem of remembering not to move them, but I find it much easier to leave them there and not move them accidentally. I myself am in the middle of sorting my images out in this way and it is a long job but worth getting done. I am toying with the idea of somehow marking these images in DTP with some sort of warning signe to alert me to the fact that they should not be moved, perhaps a flag but am open to ideas, a colour would be useful? Good luck with it Terry! :slight_smile:

In reply to myself I suppose the obvious answer is to label the item not to be moved!..Doh… :blush:

I know nothing about Reunion, but this doesn’t sound like a “shortcoming”. Most apps behave that way. If you move a file that DEVONthink indexed, then DEVONthink loses track of the link. I realize that it’s a frequent request to have DEVONthink track indexed files as they move around the file system – but, IMO, expecting an app to keep track of the current location in the file system of every file that app has been made aware of is a rather expansive (maybe also expensive) view of the app’s responsibilities.

I think Jim’s example is the way to go – though because of the Reunion dependency I suggest that the “Images” group in his example (the equivalent of @T_Smith’s Pictures repository) be an indexed group and not stored inside DEVONthink. Except for the images, all the other genealogy files could be imported into DEVONthink and managed there. This case blends well with @Allsop’s recently posted genealogical research use case.

Of course, I’m not the one who’s being advised to revise the data relationships in @T_Smith’s 150 folders and subfolders in order to follow my advice :cry:

Thanks Korm, Andrew-Bede and Jim.

Taking something from each of your suggestions, I think there’s a solution in sight.

I’ll leave my repository of images in the Finder and continue to populate it there. It’s convenient and uncomplicated. I’ll index the repository in Dt and replicate the images in Dt as as required. I’ve tested it, and it seems to work seamlessly. The images are “there” in Dt and will facilitate the research while the originals are easily accessible by Reunion for its needs.

As to keeping the nested folders in Finder: time will tell whether it will be better to manage an indexed set of groups in Dt or to bite the bullet, abandon the Finder setup, and move the entire structure into Dt with the only indexing done from the repository as described above.

Now that you each have contributed to what appears to be a very workable solution to my dilemma, it will be a few days before I can test further while some family members come to visit. I may be back to revisit some aspect after some experience.

Please count me among those who have seen firsthand the value added by you here on this forum who bring such a wealth of knowledge and experience to bear and are willing to offer your assistance so generously. I truly appreciate your help.


Sounds good to me :slight_smile: Keep me posted privately how it goes.