The outcomes of some specific index group/item operations in 3.0 are not mentioned in the help. I tested and observed the outcomes and would like to confirm whether those outcomes are intended.
(1) Delete item/s within an index group vs delete an index group: If only item/items are deleted, DT will automatically delete the same file/s in macOS folder when the trash in DT is emptied. If an index group is deleted and trash in DT is emptied, then DT will automatically invoke the dialogue box to ask whether to delete āOnly in databaseā with no change in macOS folder, or to delete the files within but not the macOS folder (āFilesā) or the entire linked macOS folder (āFiles & Foldersā).
(2) To unlink a macOS folder is to delete the index group and choose āOnly in databaseā when emptying the trash in DT?
(3) After the deletion of an index group, and if āFiles & Foldersā is mistakenly chosen when emptying the DTās trash, the deleted files can still be recovered in the macOS trash but not the deleted macOS folder?
(4) Deletion of index item with replicant/s: ALL instances of an index item (replicants and original source) must be deleted in DT for the linked file to be deleted in its macOS folder?
(1) Thatās correct. In the first case youāre deleting items from indexed groups and this is synchronized with the filesystem, in the second case you may only want to remove the reference.
(2) Correct.
(3) The original folder structure isnāt retained in the trash.
Step 1 doesnāt work for me reliably in that I delete some files from an indexed folder (pointing to a folder in Dropbox), then empty the trash and the files are usually not deleted off the disk.
I say āusuallyā, because occasionally the file is deleted in Dropbox as expected, but most often, they arenāt touched. (Out of ten attempts, two worked as expected.) A few minutes later theyāre reindexed back and appear once more in the in the indexed group in the database.
Happy to do some testing - what would you like me to look for?
Yes, theyāre in an indexed group and each has the indexed icon.
I choose the ādelete files from diskā option when prompted ā but Iām not prompted every time. I always get the āAre you sureā message, but I havenāt had the second ādelete on diskā message for a while. Thatās true even if I reset the Alerts in Preferences.
One final thing: these were created in DT3. However, Iāve just tested it by dragging adding files to the folder in Finder.
The first was deleted correctly: but I only had the āAre you sureā warning, then the Dropbox āyou know this will be deleted everywhere dialogueā. I didnāt get the second DT3 dialogue. On this first occasion, the delete worked. However it failed every time from then on.
Iām seeing this problem on both laptop and desktop. Iāll do some more testing when Dropbox isnāt involved just in case thatās complicated something, so is there anything you want me to look for specifically?
Iād just like to add that the handling of deletion (and moving files among folders within a indexed parent folders) is SO much better in DT 3.0. I used to have to use scripts and remember to trigger syncs for this to work before. Now it just āmakes sense.ā Thanks!
Thatās correct, you should only get this alert if the trash contains an indexed item not located in an indexed group and then and only then you can choose whether you want to only remove the reference or also the file/folder.
Did the deletion fail of the file in the Finder fail? But DEVONthinkās trash was emptied successfully?
But I get it the first time when I was deleting a file in an indexed group. Every group / file I test is indexed for the purposes of these posts.
Thatās the problem: as far as I can tell when I delete a file in the index group and empty the trash:
if I get the message, the file is deleted in the Finder
If I donāt get the message, the Finder file isnāt deleted when I empty the DT3 trash.
My plan is to create a test database (unsynced and with folders not in Dropbox) to see if I can tie anything down to find out whatās happening. Any pointers / settings / logs what will help?
Just checking. For the files you delete, do they have replicants in 3.0? If you have created replicants before (sometimes u may not be aware of their existence), the file wonāt be deleted in macOS folder unless all instances of such file/s are deleted in 3.0.
Good point, thanks ā but no, they are all single instances (neither replicated nor duplicated).
Iām wondering whether there is some odd combination of Dropbox / Syncing at play here, so Iāll try and strip it down to the essential and see whether that helps.
All tests are in a new database on High Sierra 10.13.6, using the download version of DT3 Beta 1. Standard for all tests:
create a folder in the Finder then index it in DT3
create a .mmd file inside the finder folder
create a .mmd file inside DT3 in the indexed folder
delete both .mmd files
empty trash
Test 1: Finder folder outside Dropbox
Both files deleted succesfully from finder
Test 2: Finder folder inside Dropbox
Both files deleted successfully from finder
Test 3: Index the problem folder (the one which caused me to report the bug in the first place) which is at ~/Dropbox/Shared/Journal/.
Both newly created files deleted successfully from finder
Existing files are not deleted from finder.
In the screenshots below, the 3 files to be deleted are the two named Testā¦ which are new, and the existing file named %year%%month%%day% JXX Daily Journal.md
The permissions seem to be the same for all the files (ls -ltr in Terminal):
Pre-delete in DT3:
When I delete (and empty trash) those three files, only the new ones are deleted.
So, there seems to be something about the existing files which is causing a problem, but itās not clear what from the permissions.
Does quitting the Dropbox.app make a difference? Or is it possible that these files were indexed multiple times, e.g. to different groups/databases, or are replicated? In these cases the files wouldnāt be deleted in the Finder as there are still references in the databases.
The files themselves arenāt replicated anywhere, and neither is the indexed group replicated. However, it has been in various locations in DTP over the last couple of years, and itās been written to by various programs (its purpose is to let me write journal entries to it from anywhere from any text editor on any platform and for them to be indexed not DTP for searching / storage. I have similar ones for notes.)
To test whether it was a problem with the folder rather than the individual files, I created a new one in Dropbox and copied all the old files there. As far as I can tell (but with limited testing), deleting works as expected - so it looks possible that itās a problem with the indexed folder itself. Iāll monitor it to see if the problem resurfaces.
To provide a bit more background in case itās relevant:
My setup is:
Desktop DT3 as the DT āserverā with the databases permanently open.
Laptop DT3 syncing to the desktop automatically via Bonjour (no sync store)
2 iPads each running DTTG, syncing via Bonjour with the Desktop.
Most of the time I work directly in DTP/DTTG with imported files, but I have three folders which are indexed (Journal, Notes, Todo Lists) in Dropbox so I can write to them using any text editor from any device.
Is there anything in that setup which could trigger this sort of problem?
