scp.py
scp.py copied to clipboard
Permission errors for recursive transfers
Is it possible to emulate the native scp
command's handling for when it comes across a permission error on a file within a recursive transfer? For example, the operate
user in these cases doesn't have access to the op-script.log file (only root
has read access). The scp
command handles permissions errors natively on mac OS X by just continuing with the next file:
$ scp -r [email protected]:/var/log ~/desktop-link/scp/
[email protected]'s password:
utmp 100% 0 0.0KB/s 00:00
pppoed_era_jpppoed_era_in_progress.log 100% 610 0.6KB/s 00:00
pppoed_era_jpppoed_era_in_progress.log.2 100% 611 0.6KB/s 00:00
**scp: /var/log/op-script.log: Permission denied**
pim_log 100% 14KB 14.2KB/s 00:00
pim_log.0.gz 100% 12KB 11.9KB/s 00:00
[...truncated for brevity...]
Here is an implementation of the SCP module for python:
Traceback (most recent call last):s/nprintz/desktop-link/scp/log/log/pppoed_era_jpppoed_era_in_progress.log.2
File "jaide.py", line 302, in copy_file
scp.get(scp_source, destination_file, recursive=True, preserve_times=True)
File "build/bdist.macosx-10.9-intel/egg/scp.py", line 143, in get
File "build/bdist.macosx-10.9-intel/egg/scp.py", line 276, in _recv_all
scp.SCPException: scp: /var/log/op-script.log: Permission denied
T1351695717 0 1351695717 0
I removed the error catching for SCPException so you can see the stack trace. This implementation is trying to receive a directory from a Juniper device (which runs on FreeBSD).
I didn't know if this was a known limitation that can't be helped, or if there is a way to skip and continue on to the next file. Perhaps an optional parameter could be passed to get()
and put()
to allow for skipping permission error files, or throwing an SCPException if the implementation desires it?
Good points. Let me see what I can do.
I got around to working through some test cases. As nice as this is, I'll have to put it off until I can get a full test suite implemented, so I can safely do some major refactoring (also applies to #33).