Tatsh / deltona / 26348532238

100%

push

github

utils: add per-file bandwidth limit to secure_move_path

`secure_move_path` takes a new optional keyword
`bandwidth_limit_kbits: float | None = None`. When set, every
`sftp.put` call receives a sleep-based callback that throttles the
transfer to the requested rate in Kbit/s (so 1024 means 128 KB/s).
The limit is enforced per file: each upload starts a fresh
`_BandwidthLimiter` and sleeps after every paramiko progress
callback for as long as `bytes_transferred / byte_budget` exceeds
the real elapsed monotonic time. For directory transfers this
means each file is independently bounded to the rate rather than
the sum being bounded; multi-file dir copies converge on the same
ceiling because every file in the loop is throttled.

`smv` exposes the new keyword as `-l KBIT_PER_SEC`, threading the
value through `smv_main` into `secure_move_path`. The option
defaults to `None`, so the no-limit path stays unchanged and
`sftp.put` is called with `callback=None` for both the file branch
and the directory-tree branch.

Also drops the two remaining "matches scp -l" comparison phrases
from `secure_move_path`'s docstring and `_BandwidthLimiter`'s
class docstring, plus the equivalent CLI help-text mentions on
`-l` and `-B`, per the rule that help text describes behaviour on
its own terms instead of by analogy.

Three new tests in `tests/test_utils.py` exercise the limiter:
that a callback is installed when a limit is given, that the
callback sleeps for the expected delta when transfer is ahead of
budget, and that no sleep happens when transfer is already behind
budget. Pre-existing tests that asserted on `sftp.put.call_args`
are updated to expect `callback=None` in the no-limit case. A new
end-to-end test in `tests/test_admin_commands.py` verifies that
`smv -l 2048` propagates as `bandwidth_limit_kbits=2048` to
`secure_move_path`, and the existing `test_smv_main_success` is
updated to expect the new kwarg in the call signature. Coverage
for both `deltona/utils.py` and ... (continued)

422 of 422 branches covered (100.0%)

Branch coverage included in aggregate %.

19 of 19 new or added lines in 2 files covered. (100.0%)

3479 of 3479 relevant lines covered (100.0%)

5.0 hits per line