Dropbox asks if I want to remove a document right after I save it

[dimalique]

For the last couple of days, whenever I have saved a Photoshop or an Illustrator document to Dropbox, I have received a pop-up message right afterwards that says:

"Remove "name of document" from your Dropbox account and all devices? If you move this file to $Deleted, it won't be available in Dropbox or on any devices."

I want to know how 'save' is being translated into 'delete'. I don't feel comfortable saving to Dropbox now, because I don't want to lose what I'm working on. Yes, I click on Cancel, but I have no guarantee that this will work every time (after all, I'm saving the documents and I'm getting "do you want to delete"). Does it possibly have anything to do with Dropbox telling me it will take 2 days for my files to sync? (BTW, I have the fastest internet I can buy and have checked the "Don't Limit" bandwidth option on my desktop. On my laptops, I have "Limit to" checked and put in a huge number just so I can get a couple kb Word doc to upload in under a day. I've been fighting this poor upload speed for months, and find it very frustrating since I don't have this difficulty with any other service I subscribe to).

[XPI]

Yes, please fix this! It is a huge and potentially damaging (as in 'liability for Dropbox') issue.   I had a user here hit yes....fortunaly it was a minor work.   

In my case it is a large (.psb) file that is doing it. I think the one that got deleted was too.

[Lusil]

Hey everyone, thanks for nudging us back on this thread.  

You are right, when you're done editing a file with the third party apps you mention you get the error message for, the best way to resolve it is to save the file and exit the application in question. Dropbox should then sync the file right away. 

I understand though that the message can be confusing for some of you, so thank you for taking the time to share your feedback on it. 

If you have any other questions for us, don't hesitate to give us another nudge. Cheers!

[thejerrybryan]

I can't help feeling that none of the Dropbox folks who have addressed this thread truly understand what users are reporting. The file giving the funny message is probably not the file the user is editing. It's probably a temporary file created by and then deleted by a third party app. So it's not a file that the users even see, but it generates the message. But that's not the only scenario. Another scenario seems to be a File>Save kind of operation where Dropbox sees (or thinks it sees) a delete followed immediately by the creation of a new file with the same name. Finally there is a third symptom where third party software is using a database file - NOT A SEQUENTIAL FILE - as a temporary work file. In my case, I have three totally unrelated third party apps, each of which uses an SQLite file in this manner. Dropbox will try to backup the file while it's in use. Even though Dropbox is only reading the file, the fact that Dropbox is reading the file (or maybe the way that Dropbox is reading the file) seems to prevent the third party app from writing the file when it needs to do so, thereby causing the third party app to crash. This is totally unacceptable. At least one Dropbox competitor, namely OneDrive, appears to have solved this problem. All of these problems have in common that they can be solved by pausing Dropbox while the user is working and resuming Dropbox after user completes processing. Users should not have to do that. Rather, Dropbox should take measures to deal with these problems in such a way that Dropbox's operation is transparent to the user instead of creating bogus error messages or crashing third party apps. Dropbox didn't used to do these things. I can only suspect that Dropbox has been "improved" by being made "smarter" and now Dropbox is too clever for its own good. Another "too smart for it's own good" thing is that RM follows file renames when I think it shouldn't. I often rename a file to make a historical, point-in-time backup and then I make a new copy of the file with the original name. This seems to wreak havoc with Dropbox's logic to provide the version history for a file. I probably should copy the file instead of renaming it, but renaming it seems so much more natural and is so much easier.

Jerry Bryan

[jeffcogswell]

I'm going to add my two cents just to bump up this issue again. I think Jerry is exactly right, it has to do with apps that are creating temporary files and sqlite files, etc. I'm using FL Studio (a music production app) and I recently moved one of my folders into my dropbox directory. The app creates temporary files and when it's done it deletes files and renames them all without the user being aware of it. And dropbox is freaking out over this, giving me this same error message. I checked and indeed my files *are* present, so at least I'm not losing them -- SO FAR. But Dropbox needs to work on this -- test with FL Studio, Photoshop, other "big" apps that do this kind of thing -- and find a way to (a) prevent the annoying error message and (b) *NOT* lose any actual files, and (c) *preferably* not upload and track the temporary files.

I'm a software dev by day, so I know how this works, and it's not that difficult: Unit test with these apps I mentioned above, and make sure the QA/test team does the same. Please?