Here is a trick I want to share:
We can replace a file with its DT link unchanged.
Right click the file and click on show in Finder to find the file in finder
Replace the file there and make sure the old and new file have the same file name
Application situation:
I use DT to track my scientific project and record all the figures. Sometimes I need to update a figure because I add some new lines or I did something wrong on the previous figure. However, I already refer to this figure in my note using this DT link, so I need to replace the figure without changing the DT link.
Last word:
I know it is not recommended to modify the database directly, but otherwise I need to modify all the DT links in my note and that is annoying. I hope that DT can add a function that we can replace a file without changing the DT link so that I can avoid this dangerous operation.
True, oh so true. What do you do if that breaks the database?
There might be alternatives.
You could open the figure from DT in your favorite figure changing app, apply your changes there and save it again. That way, only the content changes, not DT’s UUID
You could store your figures in an external folder (i.e. external to DT) and index that. Then, modify your figures with your favorite figure modification app and update the index in DT.
I suggest that you try that instead of jeopardizing the integrity of your data.
As long as the filetype & filename are identical, this shouldn’t break anything. But I would also recommend to simply edit the file (in DEVONthink or externally).
DEVONthink should automatically update the index and checksum after receiving the filesystem event. If that should fail (e.g. if the volume containing the databases doesn’t support it reliably), then File > Update Indexed Items should help.
I will try to use the linked file method.
I cannot directly modify the figure since these figures are automatically produced by some Python program.
I still have one question. How DT distinguish that a file is modified by external application and replaced by me. Is there any system-wise ID that stays unchanged with modification and changed with substitution?
I tried my method and it works. So I come to a theory that the DT link only depends on the relative path and the name of a file, and it does not depend on the content of this file.
If the DT link depends on the content of this file, then it is impossible for us to modify the file using external application with DT link unchanged.
DEVONthink usually receives a filesystem event and automatically handles this, otherwise use File > Update Indexed Items as suggested (even if it’s not indexed).
Let me repeat your word to make sure that I understand it correctly.
My replace-file-trick works as long as the filetype+filepath+filename do not change. And it will be safer if I run a Update Indexed Items operation, which will do some check for the file, even if they are not indexed.
I have a few cases where a PDF is replicated to 3 or more locations in a database.
When I get an updated version of the PDF, I have to delete all the old version (replicants) and replace.
Up to now I have always deleted all replicants, added the new file and then replicated the new file to the locations accordingly. Time-consuming, but I have never found another way.
I tried the above and it works very well. Unless I have missed an easier way, then I think I’ll try doing this in future (very carefully of course…)
I have a similar scenario on my hands: PDF documents are produced by a third-party application and I need to replace the version currently stored in DevonThink.
The trick described by the OP works.
However, I wonder if this kind of replace operation could be supported by some integrated functionality that could be called “consolidate” or similar. Users would select two documents, invoke the function and specify which document to treat as the current one. Ideally, this would then also ask whether to transfer all (custom) metadata from the previous version to the replacement. But this last part might be quite specific to my own needs.
When thinking about your proposal in (relational) database terms, it seems to make perfect sense. The UUID (which the link refers to) is similar to a primary key, and it is perfectly ok to modify the content of a record without modifying its primary key. I wouldn’t even think about
because all that happens is the exchange of one “column value” (again, in relational database terms) by another one. In this case, the “column” is the file, and the rest of the data for this UUID should simply remain the same.
Behind the scenes, DT would have to re-calculate the checksum, but that is something that’s likely happening anyway when a record’s data are changed.
But this approach would probably require a conceptual change. Currently, a “record” is a synonym for a “file” and has no life of its own independently of this file. For your proposal (or rather my idea how to implement it) to work, all data related to a record would have to be treated equal, so that one could simply change the “underlying” file without changing the UUID.
I’m intrigued by this issue since I use the Server function to access my DB when away from home–and I’ve struggled to find a way to edit a record on say, my work Windows machine, re-upload it to DT through the server, and not have it break any links I may have created (to my knowledge this isn’t actually possible at present).