I have the same issue on the PC version. I’m trying to download my entire ACD to my computer via syncing, but it does not sync all of the files. This is a deal breaker for me, and I’ve been a paid odrive user for a while now (I started when it was free). I shouldn’t have to resort to attempting to use a script to complete a task that should work in the application.
Happy to report that I’m now 80% of the way since invoking the CLI script. Thanks, Tony.
i think the obvious feature request is to allow users to force Sync as the default implementation appear to be susceptible to timeouts and exceptions.
Any plan by the Product Owner to add this to the feature backlog?
I apologize for the frustration. Currently certain exceptions or several exceptions will cause the bulk sync operation to abort. Amazon Drive tends to have a high percentage of exceptions to requests, so it is more common with that integration.
We are working on functionality that will be much more tolerant and continue to download until it is done (similar to the script above). For now the script will get you there, if you want to give it a try.
BTW, I just noticed another rather material benefit apparently from utilizing the CLI script. Previously, all of my .dmg and .iso files that I had uploaded to the ACD, when retrieved using the regular Sync function were corrupted and I was not able to mount them on my OS X. Surprisingly, these files that have been downloaded via the CLI script now all appear to be functional and mounts!
If you know why this is so, please explain as I am curious. Thanks!
That is certainly odd.
The CLI is only telling the desktop client what to do, so the sync function is the same. Since only the interface used to instruct the sync engine is different, so there should be no difference in the resulting file download.
I’m not sure what’s up there, but I’m glad to hear everything is looking good now.
I also assumed the functional process between the CLI and Sync are the same. And note that these file formats are not amongst the supported types listed on ACD and repeatedly when I had previously tried to access these files, upon downloading them either through the Sync function via odrive or directly from ACD webapp, I was unable to open them. But voila! Now I can.
I had uploaded prior .dmg installers for my tax software archive that I presumed were long gone. Every one of these files and disc .iso files I downloaded with CLI now mounts!
Still, I’m curious as to why?
Good question. I actually don’t know. Perhaps Amazon had an issue they fixed on their side? If you download one via their web client, again, does it exhibit the same bad behavior?
Maybe odrive is just magical
Premium user here, troubleshooting why sync (windows, both options selected) isn’t recursing into all subdirectories consistently. Been trying to clean up / diff 3 machines to get a known good state downloaded to my desktop. I keep finding paths that begin having
.cloud* extensions again but seems no rhyme or reason. Trying to find a way to thoroughly check all these paths and make sure I have a known good working copy before I move files around anymore (saw the note on moving .cloud files is not very well supported). Should I still be able to use this powershell snippet or is this not what i’m looking for?
Generally the issue is getting that first, full recursive download run to go all the way through.
If you are trying to get everything down, and want to make sure that odrive just powers through all transient exceptions, you can use the script snippets to do that.
Give it a try and see if it gives you the desired effect.