After I fixed permissions and synced some files they got deleted from my Dropbox folder

The thread I refer to is:-

https://www.dropboxforum.com/discussions/101001014/the-dropbox-app-cant-sync-one-file/441394

Thanks for the post, benmack.

Just to make sure I got this right, after you chose the "fix permissions" option from the Dropbox preferences, the files that were giving you an error did sync to your account online, but after syncing they got deleted from the Dropbox folder and are only available online, is that correct?

That's pretty strange indeed; do the names of these files perhaps contain any of the characters in this article?

Are you able to open and preview them as normal on dropbox.com?

Keep me posted.

Hi Hannah, thanks for your reply

Re filename characters, they all contain a period (.), as do most filenames, I'm not sure why that is on the list... But otherwise no. An example affected filename is "Sample_NDA.pdf"

Full path on local machine is "C:\x-files\Dropbox\Designerds team folder\designerds\admin\agreements\nda\samples\Sample_NDA.pdf"

So apart from the spaces in "Designerds team folder" and _ and . in filename, nothing unusual

Yes I can open and preview them on dropbox.com

Aha! Yes, that worked. As it restarted it downloaded the missing files. Thank you, why didn't I think of that before.... 

Although of course I'm still nervous about what went wrong, I don't want dropbox deleting my files... And I still can't find a list of affected files in the log (so I can check them) - I saw the files appear briefly in the app's activity window as they downloaded, then they disappeared. Is there a proper log file anywhere? Google suggests not and I can't find anything in the usual places.

And as an aside please could you clarify that filename guidance that Hannah posted. Lots of my files have periods (.) in filenames, not just for the extension but elsewhere as well (e.g. fred.blogs.doc) - this is a perfectly legal windows filename, why would dropbox not like that? And whilst the other characters in that list might not be legal under windows, some are legal in linux etc., what happens then? Getting nervous about dropbox...

Thanks again

I don't think you're running into issues with file names. Dropbox handles file names with periods in them just fine. The only exception to that is when you're on windows and the period is at the end (either after the extension, or perhaps if there is no extension like on a folder name). Those names are illegal on windows, and so we don't currently download them to windows devices. (tangentially, we're currently rolling out a feature to allow these files to sync down: https://help.dropbox.com/sync/flexible-filenames)

I believe what went wrong here is roughly:
* We keep a list of files that are running into permission errors, so we don't spin CPU re-checking those all the time
* If there are any changes on the server that need to be downloaded, where the corresponding file on the local machine is running into a permission error, we mark that as "unreconstructable" for similar reasons - essentially "pretending" that the file doesn't exist, again so we don't waste CPU. (this only applies to the local state - so the file on the server, supposing it existed, would be fine)
* Anyway - when you fixed the permission error, I think what happened is that we didn't remove that file from the list of files known to be spinning on permission errors quickly enough, and it ended up getting marked (incorrectly!) in this "unreconstructable" state (if it wasn't already in that state, which it might have been)
* "unreconstructable" is a state we only keep in memory as the sync engine is running, so restarting the client naturally clears this state and we keep running.
* What should happen is should be detecting that we're no longer getting permissions issues, and we should unset all those related states in the engine, so you don't have to restart the client.

This is certainly unintended, and I've filed a bug internally so we fix this up.

Many thanks for that excellent reply. Good to know what happened, and good to know it is now on the bug list.

Would be nice to have a log file I could check, to see what files were affected.

And maybe worth updating that page about filenames, I imagine it is not just me that is alarmed by it.

Thanks