I like to create a folder on the desktop, put some stuff in it, and finally import the folder into DT. I just realized that file links within this folder (e.g. pdfs linked to my downloads folder) aren’t imported into DT!? Is that how it’s supposed to be? Am I missing a preferences setting?
Thanks for your help,
Aliases inside folders aren’t resolved while importing/indexing but aliases selected via File > Import > Files & Folders… are resolved.
Following aliases (and presumably symlinks) to files when importing might be acceptable, but following any to folders could result in importing a lot of unintended content.
In the past this has caused a lot of confusion, e.g. causing duplicates or issues while synchronizing, and therefore we’ve disabled this again.
Mhm, in my opinion this is at least confusing! In the example above I may deal with this behavior - but I also have huge project folders (and not necessarily control over them) that could contain aliases deep down the tree. These aliases will get lost (even aliases to files within the folder structure) which is a problem for me - and in comparison to unintended imports definitely a bigger one.
I agree with that choice since it causes less trouble/confusion for me.
Instead of silently ignoring aliases/symlinks during importing/indexing I think it would be helpfully informative if their pathnames appeared in the Log window. That won’t resolve kallovsky’s issue but at least it’s somewhat of a compromise.
Yes, listing those aliases that have been omitted in the log file would be a good compromise! Christian, it would be great if you could consider this!
Thanks for your help!
Thanks for making me aware of that topic - I did not know yet that links are just ignored by DT.
I just made a short test with a new empty test database and took one folder which contains many links to other folders.
I imported and indexed it and it contains - nothing.
IMHO, that would be the least.
My suggestion goes a little further:
Why can’t DTPro take the aliases as what they are (aliases) and import them like that (with no content but as a link to the content).
That would seem to me more logically, because the structure of the data is there and
a) by clicking the links in DTPro (like with an alias in OS X) you could jump to the contents.
b) by creating an intelligent group collecting all aliases, you could see what was omitted during the import/index. (and potentially add it “by hand” to the database)
Where is the content being linked to?
Not necessarily, which relates to my question above.
Apply your idea to this example:
If ~/Documents/Private is an alias or symlink to /Users/Shared/Public and the former is imported into DT what would the new corresponding DT document look like? Presumably its Path metadata field would contain a relative pathname to an alias or symlink referencing /Users/Shared/Public, or a direct absolute pathname to /Users/Shared/Public. Or use the URL metadata/field?
The actual “structure of the data” for /Users/Shared/Public would remain only external, not internal, to DT. In other words, there’s no DT document for it, so …
Presumably that would “access” /Users/Shared/Public externally (with either Open-like or Show In Finder-like behavior?) since there’s no DT document to “jump to”.
For now I’m ignoring issues (if any) with indexing since I don’t use it.
Hypothetically it seems something like that would be possible, and if technically possible a bit surprising it’s not already implemented. I’d actually thought about it but lazily assumed Dtech had already considered and had reasons for not doing it. That’s why I limited my compromise suggestion just to Log entries. So, thanks for the further suggestion and questioning that my a§§umption inhibited. [edit: to avoid stupid censor filter]
Basically, making it easier to manually “follow” aliases/links.
I admit, I did not describe in detail what I thought.
You described it very well by the term “manually follow aliases/links”.
I would expect this “link” type of DevonThink object to act like an Alias in OS X does:
by clicking, it do what clicking the link in the Finder would have done: open externally the object which is linked by the Alias (a folder window or a file).
If there would be a context menu to index the contents of this object (for a folder maybe with the option to limit it to n levels of folder hierarchy), this would be even more luxurious.
Thinking about this more and doing some testing (including indexing, which I’d wanted to avoid), I’m not fully understanding the choice for DT to ignore (silently) all links (aliases/symlinks) within folders when importing/indexing instead of creating a document with a Path to the link destination. Couldn’t they be treated similarly to what happens when indexing links for individually selected files, but without any attempt to follow them? When a command to create symlinks like:
ln -s /some/destination/path myname
… is run it doesn’t know or care that /some/destination/path exists.
That it’s possible to import/index individually selected links, while those same links will be ignored if importing/indexing their parent folders, seems peculiar.
Also, when links to selected folders are imported/indexed those initially links are followed and their destination folder hierarchies (with non-link files) created as group hierarchies in DT (with documents). That’s more aggressive than simply creating empty groups with a Path to destination folders would be.
I’ll stop, for now, before this gets any more confusing.
I absolutely agree with sjk