Replies: 2 comments
-
|
Your description indicates that some rename operations probably failed because of request throttling from Dropbox and thus the file is restored at the previous location. If you can reproduce we are happy to have a look at the log file you can share with mailto:support@mountainduck.io. |
Beta Was this translation helpful? Give feedback.
-
|
I copied a large folder to my Dropbox and waited for them to completely sync. I then moved the files from within a subfolder to the enclosing folder. Only a small subset of the files transferred. When I looked for the log file, I discovered there is a switch in MountainDuck preferences to enable a debug log, which I did. I then moved the files that moved correctly in the previous operation, back to the original test subfolder. They initially appeared to move correctly, but some of them reappeared in the enclosing folder, and when I tried to move them individually, I received a message that there was already a file by that name in the subfolder. Eventually, the files either moved to the subfolder on their own or allowed me to move them individually. I zipped all of my log files and sent them to the address you provided, referencing this discussion. I also confirmed that this is not an issue with OneDrive. Please let me know if you need anything else. Thanks! kt |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I have a recurring issue with file updates reverting on Dropbox. I notice this most when I upload a folder of photos, then update the names in bulk using Adobe Bridge. The name changes appear to process correctly at first, but then they revert to the original names on a large portion of the files—I only seem to be able to change about five filenames at a time. This happens regardless of whether I allow all the files to upload before updating their names.
Today I saw a similar behavior, where I copied five PDF files, between 150-500 KB in size. I dragged all five to a new folder, and two of the five popped back to their original location. The last file was duplicated in both the old and new locations. I believe both of those were readable, but I've encountered a similar behavior where one copy was intact and the other was a 0 byte file.
I'm guessing Mountain Duck reads the old names back from Dropbox before all the changes are sent or processed, although it seems like it should be able to compare timestamps and go with the more recent version. If my guess is accurate, then this would be a race condition?
I know for sure that this has been happening across multiple versions of Mountain Duck on Dropbox using both Smart Sync (IIRC) and Integrated connections. I don't recall this happening on OneDrive or Google Drive, but I use those less. I also use Mountain Duck under Windows on my work computer to sync one relatively small work transfer folder to my personal OneDrive and haven't noticed this behavior. I used to sync that with the native Windows client, but we've started blocking non-enterprise OneDrive accounts, and I had to switch. I'm a naughty IT tech.
I haven't seen this at all on iCloud with the native Apple sync, although I've seen wonky behavior from multiple non-Apple cloud storage clients using Apple File Provider over the years. I also haven't tried the official Dropbox client in a while and don't know if that would have the same issue.
tl;dr Has anyone else seen Dropbox files reverting to their old names and/or locations when making bulk updates?
Beta Was this translation helpful? Give feedback.
All reactions