I have the option to store images and PDF’s in the DT File folder turned on. In DT, when I delete a PDF doc that is stored in the DT File folder, a dialogue box comes up asking if I want to also delete the file on disk. Let’s say I say “No, only in database.” The doc in DT disappears, but the file stays in the DT File folder on the disk. OK, now let’s say I do this a lot, and eventually I want to clean up my DT File folder and remove all files that are not linked to docs in DT – is there an easy way for me to do this? The only solution I can find thus far is to Export and Import, but that is clumsy.
Circus Ponies NoteBook addresses this very issue with a “Discarded Attachments Index”. Having such a thing in DT would be very helpful. Or is it there in some other form that I am missing?
Yes, this is a bit of a problem with DT, perhaps will be changed in new versions. I have been avoiding clicking delete from disk because if you do that when deleting a link to an image or pdf file outside the DT folder then you lose the original on your hard drive. DT is not consistent in it’s terminology in regards to “where files are stored” – or, perhaps it’s consistent, but not logical.
The point I brought up is because of this: If I delete a whole group of docs in DT, some being images in the DT File folder and some being links to images elsewhere on my HD, I can’t select delete from disk or I will lose the files on my HD as well. I really think this is an unfortunate shortcoming with DT that makes me “skiddish” when deleting, because one can accidentally delete files outside the DT folder structure.
CP NoteBook treats all files stored anywhere in it’s NB file structure as “in the NB.” Links to outside files are just aliases and can’t act upon those outside files, except to open or reveal them. Files, such as images, are stored in the NB file structure in an “Attachments” folder. Deleting such a file deletes reference to the file from the NB, but keeps the file in the Attachments folder as a precaution. One can then goto the “Discarded Attachments Index” and periodically trash them all for good. This is a nice solution. And never, does trashing a “link” or “alias” to a file that has not been copied into the NB actually trash the file elsewhere on the HD. I think DT should adopt this logic. The confusion in DT comes from some things being converted to RTF and copied into the database (such as Word docs) and other things like images always being “links” - whether inside the DT file structure or not. I think everything inside the DT File structure should be considered “in DT” and everything that is linked to a file elsewhere on the HD should be considered a link. And links should not be able to trash the originals on the HD (or if some users like this for varous reasons then make it a Preference). At least this is my humble Newbie opinion…
Version 1.9 will automatically handle the “Files” folder whereas the “Delete from disk” prompt will be only related to really external material (neither stored inside the database nor inside the “Files” folder). This is hopefully consistent and logical
Ah, music to my ears! Sounds like a great improvement. Will image and pdf files stored inside the DT File folder still have “link” symbols, or will the link symbol only be reserved for “really external material”?
For the record, 1.9 fixes the problem I brought up here totally. Files stored in the DT file folder that are now deleted from within DT are also deleted in the DT File folder. And the “Delete also on disk” now exclusively refers to files outside the File folder structure. Also, the link arrow in the file icon also now refers exclusively to files stored outside the DT File folder structure. Good job.
I have to correct this statement. I have since discovered that if, in the Preferences, you have “Copy linked files to database folder” checked, then the link arrow is still present even though the file is now copied into the DT File Folder. This makes things a bit confusing in that image and PDF files copied into the file folder do not have the link arrow. Personally, I would prefer any file that is stored in the DT File folder to NOT have a link arrow. I think this is important because I want to, at a glance, know if a file is in the DT File folder structure or elsewhere on my HD. Hopefully this can be addressed… if there is something I’m not understanding about the advantage to the current behaviour then please explain it to me. Thanks.
Thank you Christian, that will be an improvement. I’m still new to DT, and just want to let you know I am impressed with your responsiveness and interaction with your users. DT is very good as it is, yet I look forward to seeing it develop even further. Keep up the good work.
One other little “consistency thing” to consider on the issue I brought up above is what symbol is displayed when a user drags a file into DT via drag-and-drop (for the rest of this post I’m speaking only of the symbol displayed as the user holds the file over the DT window just before dropping it in).
If I have the Preferences set to copy linked files into the DT File folder I get the following inconsistent symbol displays when performing a drag and drop into DT:
an image file dragged in with the option-apple keys held so it is “linked” into DT displays the “alias” arrow and provides an actual link to the file externally (totally normal Mac behaviour)
a Word doc dragged into DT with the option-apple keys held so it is “linked” into DT does the following: displays “alias” arrow and copies file into DT File folder (since Prefs are set to do that – but is not normal Mac behaviour given the symbol displayed)
As it is it does make sense given the Pref’s settings for different file types, but is a little confusing in common use. As far as I can tell this will only happen with text docs which essentially have one of 3 ways to be dragged in depending on the Pref’s setting: convert to DT doc, copy into DT File folder, or leave as true alias referencing outside file. To keep the alias arrow from having to serve double-duty on text documents it’s almost like another symbol needs to be developed to indicate a text file is about to be converted into RTF. That way the “+” would always mean a file (image or text) is about to be copied “as is” into DT, an alias arrow always means a file is truly being linked, and this new symbol (perhaps some variation on the “+” symbol) means that a text file is going to be converted into DT. I think this would be clearer, especially since dragging a Word doc into DT is not just copying it as the “+” sign would lead one to believe, but actually converting it (this is important since specialized Word formatting is lost).
This leads me to another thing I just realized: currently, when you have the Pref’s set to copy linked files into DT File folder, there is no way to override that for a text file when dragging and dropping. I think if my idea above was implemented then you could choose to drag a text file in one of three ways: by default a keyless drag and drop would convert it into DT (new symbol displayed), option key held would display “+” sign which would copy file into DT File (which is normal behaviour for the Mac Finder when a + is displayed), and option-apple would link file in (displaying the alias arrow). In fact, these actions could be consistent no matter the Pref’s setting chosen for “copy links to DT File”, since that Pref’s setting would only effect Imports that were not drag and drop. For images and PDFs nothing would change from the way it is now: the default keyless drag in would still be a “+” sign copying it into DT, and option-apple would change this to a link action only. …Does this make sense?
Just an idea I had today, think about it, there may be other issues I’m not considering…
Awhile ago I made a choice to limit the number of database items with links to external files so I’d be less confused by their actual locations.
Slight tangent…
What’s missing (AFAIK) is a way to easily generate listings of items internal to the database or that reference external files. And the ability to check if items have orphaned links to external files.
In general, a bit more maintenance-type functionality would be helpful (e.g. “Search by Kind”). A kludgy workaround might be to replicate the History (since it’s a complete linear list of items) to a temporary group in List View, then add columns that help identify items of interest. Unfortunately while composing this I’ve managed to lock up DT Pro doing that and invoking Show Info on one item to check how well it might work. I’m about to abandon hope of it returning control and just Force Quit it…
Okay, I’ve restarted DT Pro and removed the temporary group, but it still contains replicated of all locked items. And unlocking them would unlock all replicates so I’m not sure how to get rid of this unwanted batch. Whoops.
Warning: replicating locked items may have an undesirable side effect on your database.
I’m still a little confused about this “Some files are represented on disk. Also remove from disk?” query when deleting files in DT 1.9.2. Does this only remove files in User>Library>Applications Support>DEVONthink or does it actually remove the original file that might be in my Documents folder or a folder containing the original file and other information about that project, i.e., is it going to delete my original that was imported into DT?
When I first began using DT I didn’t realize the problem with importing my NoteTaker notebooks into the database. Having them included has sort of mucked up my searches so I want to remove all trace of these packages from DT. But I DO NOT want to erase my originals from their original location on the hard disk. I experimented a little and it didn’t seem to remove the original files but I’d like to have a little more confidence about the issue before I delete 40 or 50 NoteTaker packages from DT. I want to get it all out of DT but not totally out of my computer!
The “Also remove from disk” prompt is related to files outside (!) the ~/Library/Application Support/DEVONthink folder. Therefore just choose “Remove from database” to ensure that no files outside this folder will be deleted by DEVONthink.
OK, that’s good to know even though the test that I did didn’t seem to remove the file (but it was a NoteTaker notebook file, i.e., package so that may have been why.) OK, how about this - when you select the file and use command click to get the contextual menu you are offered the choice “Delete All Instances.” Does this remove only the “Instances” in the database or also from the hard disk outside of DT?
