I’m trying to download my ACD contents before the end-of-the-month so I don’t have to renew after Amazon changed its terms by no longer offering unlimited storage. I’m currently syncing my contents from ACD to my external drive and while it is progressing, intermittently it hangs up the sync and reports internal error from ACD. Reading various threads on this subject, it appears some network interruptions may be causing the time-out. I’ve read elsewhere regarding using the odrive CLI to essentially "sync until done" but the thread appear to be providing how-to for a windows user using command prompt. I’m a OSX user. Can someone advise me on setting this script so that odrive automatically re-engage to sync my ACD contents? I am a Premium service subscriber.
I am also trying to sync Amazon down to my server again to move to Spideroak unlimited and constantly getting the internal server error
In addition the odrive client is reporting a folder is synced with a blue tick and yet sub folders and files are not synced. This is painful since I have to check every folder to make sure it is fully synced before syncing up to Spideroak. Is this a general oDrive issue?
So, now my issue is no longer that I’m seeing ACD internal server error at this time. Perhaps it is because the Sync process ends before any time out causes the initial problem I reported.
It is that despite having set the Sync option to Save and apply to new files and folders, which I believe means that when I set up a new location for my odrive folder (in this case my new external hard drive connected to my OSX MBP), that all subfolders and .cloud file placeholders within that parent folder will be downloaded from ACD and converted. Yet, what I am observing is that within the parent folder I have opted to Sync, as one of the subfolders within completes the download of all files within (all .cloud placeholder files downloaded and converted to its actual files), the Sync stops and the remaining subfolders and the placeholder .cloud files remaining in the parent folder that was invoked to Sync would no longer download and the status icon of the parent folder turns to the blue check mark signaling that Sync is now complete. I then need to right-click the parent holder again to re-initiate the Sync process.
Is my understanding incorrect that Save and apply to new files and folders should be persistent and ongoing until every .cloud files within the folder gets converted? If so, is there any option for me to automate this without me having to repeatedly re-invoke the Sync?
Update. I see after observing the Sync process for hours, that it is not always true that after each subfolder completes conversion of all .cloud placeholder files within to the corresponding actual files that Sync of the parent folder ceases. I’ve now seen 3 instances where the Sync process carried over to the next subfolder but eventually the automatic synchronization did cease completely. I cannot thus far isolate as to why the process terminates.
I am determining that the automatic synchronization process ended based on the status symbol on my parent folder to which I invoked the Sync (with Include subfolders & Save and apply to new files and folders checked) as well as the odrive tray icon changing to steady black from blinking pink and its top most status in the drop down menu showing that it is ready to automatic sync.
Hi @toshi and @andy,
You may have seen this in other threads, but odrive will abort the full download operation if it hits enough exceptions or certain types of exceptions. If your goal is to get everything downloaded, you can use the CLI to do so. Take a look at these posts for instructions on doing this. These scripts will sync until done, running until there is nothing left to sync.
The path inside $syncpath=" " is what needs to be changed to your specific path.
The path after “find” is what needs to be changed to your specific path.
But I’m not sure if my issue is related to exceptions.
What I observe is as each subfolder within the parent folder invoked to Sync (with Include subfolders & Save and apply to new files and folders checked) completes download and converts from .cloud to actual files, status icon of the parent folder changes to the blue check (presumably meaning the synchronization is complete); even though, remaining subfolders still contain .cloud place holder files. I have not seen any notifications of exception errors since yesterday when I encountered notification of internal error from ACD.
Can support validate whether it is due to exceptions from the diagnostic data?
Yep the misinformation on blue checks is now tbe main issue for me, Amazon seems to have settled down again with blazing fast downloads too. Shame Spideroak is sooo slow uploading, will probably take until November ,when Amazon unlimited runs out for me , to get all 10TB back in the cloud.
I did consider using 10 OneDrive accounts (two home licences) which for reasonable money ,even tbough with 1TB splits per id would have much faster speed and could be managed with odrive. Could encrypt with odrive for addd security too.
One of these days we may get the fabled big upgrade?
Hi @toshi and @andy,
I see. Yes, if the download job stops for some reason, the folder overlays will show a green checkmark, signifying that nothing is currently in transit and nothing is pending upload. The green checkmarks on the folders doesn’t necessarily mean that everything inside has been downloaded locally.
This causes confusion, I know. This behavior is changing in the next major release (the “fabled big upgrade” you spoke of above ), which is still coming.
If you want to ensure that everything gets downloaded, I would suggest giving the scripts a try.
If you still think something else is amiss you can send a diagnostic and I can take a look.
So, after continue to watch the paint dry on my OS X Finder, I made the following presumption based on my observation that conversion from .cloud files to downloaded target files always complete for each subfolder and I have not observed, at least in the last 8 hours or so, where such conversion failed midway through the list of .cloud files in queue within the subfolder. Assuming the Sync algorithm prioritize completing the task per folder, I thought it could very well be that I may not have stopped an earlier Sync request higher in the directory structure than the parent folder I was referring to and while I may have believed that Sync process may have truncated at each instance of the subfolder completing the conversion, the process may have continued on elsewhere within the directory structure under the ACD. Since I have fair amount of nested folders, it is not easily verifiable. Further, on my OS X Finder, it appears that timestamp of when the subfolder was updated does not percolate up to parent folders; therefore, obscuring any evidence of updates elsewhere. Still, this assumption does not explain why the odrive tray icon’s drop-down status indicated that it was ready to sync new changes and not detail any subsequent synchronization occurring elsewhere in the ACD directories.
I decided to test it anyhow and right-clicked on the Amazon Cloud Drive parent directory to invoke Stop. Then I drilled down to the folder I was referring to as the parent folder earlier in the thread (folder containing sub folders of image files) and re-invoked the Sync with Include subfolders & Save and apply to new files and folders checked) again.
Happy to report that it now appears to Sync through the subfolders, at least the last 6 subfolders without stopping.
Interesting. It sounds like, as you said, sync was still going on, in some capacity. Recursive sync will drill down the structure as it follows the subfolders, exposing the files (as cloud files) along the way, until it can get to them to download. This may be what you were seeing. The status in the odrive menu should’ve reported active files/folders, however, so that is odd.
The “Stop” option on the right-click context menu won’t actually show at all unless something is active, so the fact that you were able to select it means odrive as doing something. In any case, I am glad to hear things are progressing.
Thanks for the update!
Of course, just when I thought I figured it out when I returned home from an errand I see that the Sync had stopped again. My first attempt to re-invoke it resulted in more of the same with odrive ending the process after one subfolder had converted and the tray status showing that it is ready to sync. But I will continue to observe how it will progress.
If you haven’t already, I would recommend trying my script. You may get a better result with this less refined, but more persistent method.
I ran the script, but I’m not sure I am seeing any evidence of download to the specified folder. The tray icon and the status from the drop-down did not indicate activity or from the Activity Monitor.
Command prompt did not indicate any error when I ran the script either.
After running this overnight, I can definitely state that the script did not work.
It looks like one of the quotation marks is funky (the one after the path). This can happen if the string is copied into something like TextEdit, changed, and then copied out.
Try this command:
exec 6>&1;num_procs=2;output="go"; while [ "$output" ]; do output=$(find "/Volumes/moana/odrive/Amazon Cloud Drive (SID)" -name "*.cloud*" -print0 | xargs -0 -n 1 -P $num_procs python $(ls -d "$HOME/.odrive/bin/"*/ | tail -1)odrive.py sync | tee /dev/fd/6); done
I see, I thought that I needed to apply backslashes “” for spaces and special characters.
I can confirm that when I copy & paste your script directly into my terminal and submit it, I see both process response within the terminal window and the status on the odrive tray icon responding.
Since I want to prioritize which directory to download first, what I did was to submit in the the terminal window, the following command,
exec 6>&1;num_procs=2;output=“go”; while [ “$output” ]; do output=$(find "/Volumes/moana/odrive/Amazon Cloud Drive (SID)/Photographs/Commissioned“ -name “.cloud” -print0 | xargs -0 -n 1 -P $num_procs python $(ls -d “$HOME/.odrive/bin/”*/ | tail -1)odrive.py sync | tee /dev/fd/6); done
When I submitted this originally, it did not generate any process response. Can you check if I inadvertently added any syntax error? I believe all I did was to append “Photographs/Commissioned” to the path.
Since the path is inside quotation marks you do not need to escape the spaces and special characters.
For the command you have above, the quotes after Commissioned look suspect. You can see that they are kind of curved instead of completely vertical.
exec 6>&1;num_procs=2;output="go"; while [ "$output" ]; do output=$(find "/Volumes/moana/odrive/Amazon Cloud Drive (SID)/Photographs/Commissioned" -name ".cloud" -print0 | xargs -0 -n 1 -P $num_procs python $(ls -d "$HOME/.odrive/bin/"*/ | tail -1)odrive.py sync | tee /dev/fd/6); done
Strange. I submitted your last set of command and it did not process either.
But I resubmitted your original command and it began processing the command.
I’ve checked that the path name to the priority target is correct.
I now see that since I did not Stop the previously invoked Sync request (applied by right-clicking on the folder), the odrive tray icon status show that Commissioned folder is synchronizing along with the CLI script processes that I just submitted.
To add, once one of the subfolder within the Commissioned parent folder completed its synchronization that specific Sync process ended. I note that I can once again re-invoke Sync again on the Commissioned parent folder presumably because it is a distinct process from the CLI.
I presume there is no issue with running both processes concurrently.
The CLI is controlling the desktop client, so you should expect to see the CLI output and the desktop client status matching up.