Child Item

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

My Dropbox Plus app was showing 66 files unable to sync, saying "to sync this file give dropbox permission to access it" for each one. It has been like this for a while. The files were in my local filing system (Windows 10) but not synced to dropbox server. I could see nothing wrong with local file permissions, and they opened OK locally on my PC. But the files were not appearing on dropbox server.

So I tried the instructions in the forum thread 441394 "The Dropbox app can't sync one file" (if I include a link then it won't let me publish this, moans about html errors). I.e. Preferences - Account - click anywhere window - hold down Alt key - buttons appear.

I first tried "Fix Hardlinks", nothing happened. I then tried "Fix Permissions" - this uploaded the missing files, but then DELETED them from my local machine!

Fortunately they are still on the dropbox server (at least the one I was watching is), but I now have files on the server that aren't synced locally, and no indication of why. I didn't keep a record of which files were affected, and there were 66 of them, so I have no idea how I can find them. There is nothing on the activity log window of my local dropbox app, and it reports no sync issues. But there are now files on the server that are not on my local machine. I treat my local machine as master, so I need to rectify this.

Note they were all pdfs, I wonder if that's a clue, is dropbox trying to do something clever with pdfs and getting it wrong?

Any idea what went wrong, and how to fix it? Many thanks

Find more posts tagged with

Desktop

Sync

Windows

Insightful

Closed - Partially Delivered

Delivered

Accepted answers

radical_exponent

@benmack can you try quitting the dropbox app and re-launching it (dropbox tray icon -> user icon in the top right -> quit; then re-launch Dropbox from the start menu)?

All comments

benmack

The thread I refer to is:-

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

Hannah

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.

benmack

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

radical_exponent

@benmack can you try quitting the dropbox app and re-launching it (dropbox tray icon -> user icon in the top right -> quit; then re-launch Dropbox from the start menu)?

benmack

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

radical_exponent

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.

benmack

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