Your workflow is unique 👨💻 - tell us how you use Dropbox here.
Forum Discussion
Dropbox tries to back up a file I excluded from back up on Win11
Hi there!
DropBox Backup is trying to back up a file that I had excluded from back up.
I'm using DropBox 194.4.6267 on Windows 11 to back up my e-mails from "%APPDATA%\Thunderbird\Profiles\<my-profile>\".
In "Dropbox Backup" -> "Choose folders", I have unchecked / deselected / excluded the file "parent.lock" (%APPDATA%\Thunderbird\Profiles\<my-profile>\parent.lock), among others:
However, DropBox still tries to back it up.
To complete the backup without errors I have close Thunderbird, pause and resume sync, which defeats the purpose of having a continuous/automatic backup.
This issue (DropBox Backup accessing a file excluded from the backup) is probably a bug. Is there a better / proper place to report this issue?
Thanks!
6 Replies
Replies have been turned off for this discussion
- Nancy
Dropbox Community Moderator
Thanks for posting this here on the forum, FunnyBox.
I know you may have tried this already, but is the Dropbox app still trying to back up the “parent.lock” file even after restarting your computer and Dropbox app?
If yes, I’d like you to go to your Backups page here and send me a screenshot of what you see.
Let me know once you’ve got more info.
Hi, @Nancy ! Thank you for your message! 😄
The backup seems to complete fine...
... but I still see this when I "View sync issues":
If I restart Dropbox, it will still show the same sync issue as above, and below:
FWIW, if I close Thunderbird, then pause and resume sync, the issue goes away:
When I open Thunderbird and do a "Backup now", the issue comes back.
Hi, Hannah ! It certainly does. I've been having this issue for quite some time.
FWIW, this is not happening only with Thunderbird, I was using it more as a simple example. I recently installed a new version of Evernote, and it also has a very similar issue: file %APPDATA%\Evernote\lockfile is also excluded from syncing, yet DropBox tries to sync it, too:
So it is not an issue specific to Thunderbird. It seems like a bug in the DropBox logic, where it tries to read the file (and/or its metadata) at first anyway, instead of completely ignoring it. My guess is that the dev team could check this at the source code in no time.
