Copying from external storage
dillongaf opened this issue · comments
I have seen someone mention that they were able to get full functionality from their sd card through adb-sync but when I try to run the command with /storage/9C33-6BBD/ as the SRC I get "ls: /storage/9C33-6BBD///.android_secure: Permission denied"
What can I do to fix this issue?
You can try by commenting out this line. It's a quick hack, but it works for me. Be careful about that, you should know what you're doing.
Given the way the code is structured, it's a bit difficult for me to work on a quick and stable patch. I might try to have a look in the following days, but maybe @divVerent has a suggestion for a better solution.
Okay, I'll give that a try sometime. Thanks heaps.
Just out of curiosity, what does commenting out that one line change?
Does it just ignore the error and continue copying files? Would this then ignore other failed copy's?
I'm not very knowledgeable when it come to coding.
IIRC, errors during file copy are handled in a different way, since in that case adb gets called directly, not using that Popen wrapper (see code from this line and this line).
That line ignores command lines exiting with a non-zero status code (which might signal an error). But it does in a bit of a strange way.
Some processes exit with non-zero status code just to tell the user that they have completed the task partially or that some error occurred in performing the task, but the task was completed anyway.
In this case ls is throwing an error because it encounters .android_secure, but it's still able to list the other files (try it by yourself, typing: adb shell ls -l <target folder containing .android_secure> in a shell, then type echo $? as the next command, you should see a non-zero number).
You can also see that that error is not suddenly breaking the execution of adb-sync, because the rest of the nested calls are performed correctly, and that takes some time (depending on how big is the files structure in that filesystem). The program breaks when exiting the level of the call which received the first error (unless other errors are raised somewhere in the middle).
As you can see that flow is not optimal, since the error is basically deferred to the end of a potentially very long walk through your file tree, and it's not necessarily a breaking error.
I see, that makes so much more sense to me now. Thanks for taking the time to reply and explain it to me, hopefully I can set-up a one step backup process now when I get some free time.