Treat cloud indexed folders as removable drives

Ok, frist day, it happened one more time.

Scenario: from empty scraps folder, this morning I added 8 PDF from my Windows machine via Dropbox. Some time later, I went to my office MacBook Pro and files were indexed without any issue. Now I’ve arrived home, unlocked my iMac, and…

Upper image is after a couple of minutes iMac has been unlocked. DT3 was closed but in memory (closed this morning early via CMD-W).

After a call to “Update Indexed Items”:

After delete and empty recycle bin of one of each duplicate:

Now I open my 3rd Mac, at home. Dropbox synchronizes with some messages about “intelligent synchronization”, open DT3 and…

Afer both “Update Indexed Items” and “Synchronice” (and review each PDF to see if it what says it is:

Going back to my iMac, nothing has changed. I still have right PDFs without any duplicate. And this is why I said in other messages in other threads with my problem that I need to cycle across all DT installations to clean the mess.

Tomorrow I will repeat the same steps, but instead of clean the mess at home, I will left all untouched and check on Monday if work MacBook Pro shows any duplicates or whatever.

Forgot to say that all my 3 iOS devices have the databases disconnected.

In your Dropbox account online, in Settings > General, do you have this enabled?

If so, may I ask why?
And do you see the issue if this is disabled?

I was not aware of that option. It was disabled. And it is.

Cool. Thanks.

PS: I would suggest leaving it disabled as it definitely has the potential to lead to issues. iCloud has a similar function and I had a support ticket from someone who had issues with item links not working because iCloud decided to evict the local file for no apparent reason.

Fine. I even didn’t knew that option was available.

(BTW, I lost a lot of files in iCloud because iCloud removed them without my permission as well, and was the reason I’ve completely stopped using is, as, well, it deleted all my blog and writings history, published articles, novels… I got restored from a physical security copy, but not from iCloud).

This is killing me, really killing.

Ok, now I took my HP Spectre, went to the sofa, read all PDF in scrap and delete all but two. Returned to my iMAC, Dropbox had deleted those files in iMAC but DT didn’t updated them. Is still showed the 8 files.

I made a manual sync and DT cleared all and left only 1 file… The second one appeared in Trash folder (as DT does really don’t delete synchronized files until you empty it, it still was in scrap folder. I moved the file to Scrap folder one more time.

After that I went to my MacBook Pro, waited until DT synchronized and… generated a duplicate of the file that was deleted in the iMAC…

Today experiment. I did a little bit different today. I captured PDF via Safari Reading View, Print, Send to DEVONThink, once captured all files in Global Inbox, and marked all as read, I moved into Scraps folder. Dropbox uploaded the files successfully.

I arrived at home, activated my iMac, waited a couple of minutes with DT suspended (CMD-W from this morning), and then activated it. Result:

Then I opened the MacBook Pro, waited some time while DT was still open in my iMAC, and:

And now I have more duplicates, not having touched anything, in my iMac:

With this I finish my experiments. I don’t have more time to lose with this.

In Preferences > Sync, do you have Conflicts set to Duplicate documents?

Yes, but is a thing I expressly want, as I cannot risk lose two, for example, differently annotated PDF because I annotated both by error.

But the thing is that it is not a conflict: the document is the same, same name, same size, same date and time, same CRC… even surely same UUID.

What does this script return in the Script after selecting both duplicates?

tell application id "DNtp"
	set theUUIDs to {}
	repeat with theRec in (selection as list)
		set theUUIDs to theUUIDs & (uuid of theRec)
	end repeat
	return theUUIDs
end tell

Ok, they have different UUIDs. In this case, I had 3 of same file and 2 of other, in an external mountable disk (this is not global inbox, but a network drive).

The text in “result” is:

{“BBA940C0-68EF-4A22-9C25-9558F7D49DF8”, “1BFA182F-58BE-4C38-841C-E50BA63C5DFE”, “99661B59-C1B1-4DCB-A4AB-63ECA07581BD”, “4B98998B-C90C-4C68-B26F-B458BB7706A5”, “9D0B187A-6EFA-4446-BB61-E73643C6F2EE”}


Ok, I left the only really two duplicated files and…

{“99661B59-C1B1-4DCB-A4AB-63ECA07581BD”, “4B98998B-C90C-4C68-B26F-B458BB7706A5”}

In this case the results might indeed be the weird result of the duplication in case of conflicts. But this can & should only happen if the current file couldn’t be copied (maybe because it’s locked by another app or the permissions don’t allow it or, even more likely, that the cloud client didn’t yet download the file?). The next release will both add debug logging for this case and include a workaround. If you’re interested in a beta just send me an email.

Yes, what I think it could happen, is that the file is not yet downloaded by the cloud, and sync with the remote sync db happens faster than the cloud one (perhaps because you send a push notification to remote devices and Dropbox not). Then, when the file appears in the file system, DT gets confused and duplicates it.

And yes, I’m interested in beta-testing this issue.

The sync uses indeed push notifications.

1 Like