A few questions re deletion and replication of index item and index group in 3.0

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 Like

(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.

(4) Also correct.

Got it. Thanks for the info.

Criss,

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?

Thanks.

Were these items located in an indexed group or not? Which option did you choose in the alert?

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.

Does it work using e.g. a test folder created on the desktop and indexed?

Here are what I’ve found so far.

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:

  1. create a folder in the Finder then index it in DT3
  2. create a .mmd file inside the finder folder
  3. create a .mmd file inside DT3 in the indexed folder
  4. delete both .mmd files
  5. 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.

Turning off Dropbox doesn’t have any effect.

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?

Thanks

This setup should actually be fine.

Thanks – I thought so, but wondered if its complexity may have been a factor in the problematic behaviour I reported.