Cannot find a way to delete indexed items from DT3 DB without external files being deleted.
have multiple DBs used with DTPO and upgraded to DT3 (yea)
multiple DBs contain files and folders indexed from external folders and drives
the indexed items are placed at various levels inside the DBs. Some are entire folders indexed, some are individual files that are indexed. Some indexed items are at the top level of the DB and some are within groups or sub-groups
When deleting the indexed items in the DT3 by moving to the Trash and selecting Empty Trash, DT3 deleted 100s of MB of original files on the external drives. DTPO did not do this unless I chose the option on the deletion pop up notice.
Based a couple emails with support, I found out that DT3 acts differently than DTPO with regard to emptying the trash of indexed items. As best I know, DT3 deletes the original external file if the indexed item was not at the top level of the DB when the Trash is emptied. DT3 also now has 2 different deletion pop up confirmation notices, one of which does not let you know that the original of indexed files in external folders will be deleted from the Mac.
If DT3 deletes the original file from the Mac, I can move the original file from the Mac system trash back to the original folder on the external drive - but if that folder is indexed, DT3 automatically re-indexes the file …
The only way I have figured out for how to delete the indexed items in DT3 and maintain the original a file I the external drive/folder is move all the indexed items and groups within the DB to the top level and the move to the trash and empty. Many of my DBs have indexed items and folders located through the DB at various levels according to what makes sense for grouping into DT groups for the project/purpose of the DB.
So does anyone know how I can delete indexed entries that are scattered within a DB easily while not trashing the originals (without finding and moving all indexed items to the top level) ?
My editorial comment is that this behavior is significantly different than that in the previous version and is critical because it puts my data at risk without letting me know. It seems to have been incompletely thought through. How is one supposed to deal with DBs from DTP version 2 that use indexed items without significant surprises and workarounds. I learned of this behavior in DT3 because I had a finder window of the indexed files open and watched in horror as more than 500 MB of files disappeared. If there is a reason or use case the deletion behavior change, I would like to understand it so I can use the app safely and take advantage of the functionality. At this point I need to figure out how to deal with 7 DBs with indexed files.
Due to the tighter filesystem integration (indexed folders are now automatically updated in both directions), it’s not possible anymore to index only few items of a folder and others not. Therefore deleting an item from an indexed folder removes the original too, deleting the enclosing indexed folder asks like in version 2.
Thank you for the explanation.
The auto update when adding a file is very useful.
This behavior is not what occurs in my DBs both DBs migrated from DTPO and DBs created in DT3). I can index individual files or a few items of an external folder into DT3.
I have trialed deleting indexed entries from different levels within a Db and experience different deletion responses from DT3 that I have not been able to predictable repeat.
What is the suggested approach to removed indexed items from DBs while leaving the original intact?
Given this new integration within DT3, I need to figure our how to both manage the files moving forward and and deal with those in legacy DBs.
Just tried again - The files get indexed regardless of having an enclosing indexed group in DEVONthink 3 or not, and no alert is displayed upon in indexing.
I have external folders that are indexed and individual external files that are indexed. Some of each are located in indexed Groups, some of each are in non-indexed Groups, some of each are indexed multiple times in a DB and in multiple DBs, and some of each are replicated within a DB.
How can I learn what behavior it is built to perform?
I could not find info in the manual.
I don’t think a straightforward response was indicated here, and I now find myself with at least one of the problems indicated here. I have a folder on dropbox and I intended to index one or two files within the folder. However, the entire folder got indexed. The folder contains my entire dissertation and related files and for obvious reasons I want to be very careful here. I don’t however want the entire folder in the db I am working in. The file is big. Am I to understand there is no way to remove it from DT3?? How can this be? People make mistakes…
This is simply a guess…but I’m wondering what would happen if you were to create another folder on Dropbox and move the old folder into that. I suspect DT would then lose its indexing and you could safely delete those indexed items in DT (if they were not then automatically deleted) and reindex as appropriate.
Warning: I’ve not tried this so experiment first with some disposable test items.
Since posting my original question I did a number of tests to get a better understanding of how deletions of indexed items work (or at least what to expect) because, as you said, I do not think a complete response was provided.
to your question: I have not had, and do not think there is, a problem deleting any items from the DT3. The issue I have found with the behavior of deleting indexed items from DT3 is that I find itdifficult to understand and predict when DT3 displays the dialogue box that provides notice and choice that an indexed item will be deleted from the finder when it is deleted from DT3. Meaning that in some cases DT3 deletes the item in DT3 AND the original item in the Finder WITHOUT noticing the user.
For the situation you described, if it were me - I would make a “safe copy” of the folders and files you want before deleting from DT3. I would make those safe copies by either copying them in the finder, or by dragging the folder and items from DT3 to the desktop. Then I would delete the items in DT3.
The testing I did consisted of indexing folders and files from the Finder to DT3 in DT groups at various levels of hierarchy, moving them within DT3, deleting individual index items 1 at a time and then Empty Trash in DT3.
I found it unclear and difficult to predict when DT3 would display the dialogue box that provides notice and choice that an indexed item will be deleted from the Finder. It becomes complicated if an indexed item is moved within DT3 after it is indexed. Meaning that to know if my original file in the Finder is safe (not deleted), I must remember where and how the item was indexed into DT3 and if I moved it within DT3 since indexing it. I found that deleting the same indexed file within DT3 may yield a different result in the Finder depending upon if, and where, it was moved within DT3. Perhaps there is way to manage and control this that I have not discovered, but this unpredictable behavior means that I can no longer use indexing simply because I do not want to have Finder files deleted by any app unknowingly and unpredictably.
My testing did not include the combinations and permutations created when using replicants or duplicates of indexed items, or having a Finder file indexed in more than 1 DB. The combinations and permutations grow quickly.
I am sure the very smart folks at Devonthink have a rationale for the behavior and I know it was due to tighter integration with the Finder. I just have not understood how, what I will call, the “invisible deletion behavior” helps me maintain the security and integrity of my files without the visible, overt choice.
I’ve just encountered the same problem, I had a large folder indexed in Devonthink 3, I deleted the DB in devonthink and lost all the files in my finder folder. Luckily I noticed this quickly and recovered from a backup.
What worries me is that as I am new to Devonthink I’ve made a number of test databases to import and work with folders and files to test how it all works. When I’ve finished testing I’ve deleted the test database. I’m guessing I’ve lost some documents and folders this way, but as this has been done over the course of some months I am not sure what I’ve lost.
This is sufficient for me to stop using DT3. Additionally, since DT3, I have always had errors in my DB so it will never sync. I’m sad to say it is a disaster for me. I’m heartened by the idea that I can delete the databasse without losing the items, once I move the 100,000 items I have in DT3 to another tool. I think the messages and the responses about the behavior are totally inadequate. Any tool managing my critical data should NEVER delete data without explicit warning, not as a side effect. Really disappointed.
DT does not delete data without asking you for confirmation, in my experience. If you empty the trash when it contains indexed files, you’re asked if you want to remove them from DT only or from DT and their location in the filesystem. If you try to delete a database, you have to really confirm. But there’s only so much a program can do, considering that there are always people eager to click on OK. Regardless of the message displayed to them.
If you’re having problems with your DT installation, it might be worthwhile to explain them in a new thread and ask for help there instead of resurrecting one that’s two years old.
@ chrillek – “DT does not delete data without asking you for confirmation, in my experience. If you empty the trash when it contains indexed files, you’re asked if you want to remove them from DT only or from DT and their location in the filesystem.”
The statement is not how it has behaved, and still behaves, for me. The DT presentation of the dialogue box asking if you want to remove an indexed item from DT only or from DT and their location in the filesystem, does not always present and DT moves the indexed file in the finder to the trash. I suggest you experiment emptying DTP trash when it contains items that are indexed files inside of and outside of folders that are indexed within DTP and experiment. The behavior is different.
I have decided to live with the issue and be extraordinarily mindful when working with indexed file sin DTP as I have not found a way to back out after the unwarned delete and have the file put back into the original location within the file system or DT. Note tat the Finder “Put Back” feature for files in the Trash is not available for indexed files moved to the Finder Trash from the DT empty trash command.
My understanding is that this behavior is a result of the tighter integration with Finder. But I find it problematic and it has caused hours of file reconstruction. I have found the responses from the developer to more explanations rather than assistance with how to work with the behavior that moves files from a Finder location to Finder Trash without notice.
Perhaps I am using indexed files differently than you or others …
2 points that seem to get missed when the music is playing:
If a folder containing files is indexed AND one of its indexed items is moved within DT [not uncommon for organization purposes] say to a DT group that is not indexed, then the file and structure in the Finder remains unchanged as one would expect. AND if that moved indexed item, which now looks like a single item indexed from the Finder, is then deleted in DT – DT displays the dialogue that does NOT warn about deleting a file in the Finder. So if one may not be able to tell from looking at the hierarchy in DT for what DT will do as the dialogue box will not show the warning but the file will be deleted from the Finder.
Acknowledging the time and effort put into the documentation - the application does sometimes delete files from the Finder without warning the user. The user must remember, for all time, if the file was indexed as part of a folder or individually in order to not get caught.
If I had a wish - I would have the dialogue warning display for deleting file in the Finder when the user moves the item to the DT trash instead of when the user empties the trash.