The aforementioned script is unavailable in the gallery under “More Scripts…”. I extracted the binary .scpt file from my DTPO2 install into DTP3 but it doesn’t seem to work and, unfortunately, not having access to the AppleScript source, I am unable to debug. Thoughts? Thanks.
The first line may be the problem…should be application id "DNtp"
Thanks everyone. Weirdly, I get an -1,728 attempting to open the script in the editor. Could you kindly copy in here? Thanks.
This is a built-in function now.
Select the duplicates and use Data > Convert > Duplicates to Replicants.
1 Like
You’re welcome. 
The new function is not only faster but also undoable.
@cgrunenberg is this a warning or a blessing in disguise? 
By the way, would you kindly clarify the de-duplication criteria when indexed files are involved? When more than one duplicate is an indexed entity, I am always unsure which one will be selected.
(I did figure out, though, that the function favors indexed over imported instances.)
Actually like the old script the function doesn’t prefer certain items, the selection and the list of duplicates are just processed in the selected/found order.
Thank you, @cgrunenberg, this is enlightening but also provokes further questions! Is this “selected/found order” somehow user-controllable, or is it entirely a matter of database internals? The question is important from a usability point of view.
From a more fundamental semantics point of view, in fact, wouldn’t it make sense to replace all but one indexed duplicates with symlinks? I realize that poking at the filesystem outside the database could be frowned upon. But a properly emphasized alert should be enough, for the sake of logical integrity. I wouldn’t go as far as calling it an “inconsistency,” but certainly there is friction in de-duplicating things within the database alone, without de-duplicating the content that is actually indexed.
To make the process perfectly reversible, DT could reinstate the indexed duplicates (i.e. replace all symlinks with actual copies of the file) if the user decided to remove the item from the database.
I know this idea could stir controversy, but the analogies between replicants and symlinks strike me as too compelling to ignore.
This isn’t controllable - it’s just like the old script.
Replicants are more like hard links which are neither supported by AFPS nor by folders on HFS+ (and therefore not useful for document packages either). Another issue is that replicants don’t have any own attributes (e.g. path). Therefore this is currently not possible.
Just keep all your indexed cloud storage documents in the Inbox of appropriate Database. Then you may use reps to present them in other places of Database you want. It’ll give you:
- DT copy of the original file/folder structure of your cloud storage (which is useful)
- Possibility to make a script to automatically turn all (or all except one) dupes to reps outside this Inbox
Hope it’ll solve you problem, if I’ve got you right.