mirror of
https://github.com/RsyncProject/rsync.git
synced 2026-11-02 18:15:11 -05:00
89 lines
3.4 KiB
Python
Executable File
89 lines
3.4 KiB
Python
Executable File
#!/usr/bin/env python3
|
|
"""``--max-alloc=0`` means "the largest limit this build supports".
|
|
|
|
Three things are asserted, and the second is the reason 0 is worth keeping as a
|
|
spelling at all:
|
|
|
|
1. 0 is accepted, and a transfer using it works.
|
|
|
|
2. 0 reaches the peer as the literal "0", not as a resolved number. Each side
|
|
then resolves it against its own SIZE_MAX. That is what makes 0 the only
|
|
value correct for both ends of a mixed-word-size pairing: the ceiling is
|
|
SIZE_MAX/2, so any number large enough to be worth setting on a 64-bit
|
|
client (over 2047M) is refused as "too large" by a 32-bit daemon.
|
|
|
|
3. The parser's upper bound is still enforced. Accepting 0 again must not
|
|
bring back the unbounded ``size *= atof(size_arg)`` that was fixed in
|
|
3.5.0, so an out-of-range value is still rejected rather than wrapping.
|
|
|
|
The forwarding check in (2) deliberately inspects the argv the remote shell is
|
|
handed rather than a transfer outcome: a resolved number also copies files
|
|
happily on a same-word-size pair, so an outcome-based assertion would pass on
|
|
exactly the configuration this behaviour does not matter for.
|
|
"""
|
|
|
|
import os
|
|
import shlex
|
|
|
|
from rsyncfns import (
|
|
SCRATCHDIR, SRCDIR, expect_fail, rsh_cmd, rmtree, rsync_argv,
|
|
rsync_path_arg, run_rsync, test_fail,
|
|
)
|
|
|
|
base = SCRATCHDIR / 'max-alloc-zero'
|
|
rmtree(base)
|
|
src = base / 'from'
|
|
dst = base / 'to'
|
|
src.mkdir(parents=True)
|
|
dst.mkdir(parents=True)
|
|
(src / 'file.txt').write_text('hello\n')
|
|
|
|
# --- 1. 0 is accepted -------------------------------------------------------
|
|
|
|
run_rsync('-r', '--max-alloc=0', f'{src}/', f'{dst}/')
|
|
if (dst / 'file.txt').read_text() != 'hello\n':
|
|
test_fail('--max-alloc=0 did not copy the file')
|
|
|
|
# --- 2. 0 goes on the wire un-normalized ------------------------------------
|
|
|
|
argv_log = base / 'server-argv'
|
|
wrapper = base / 'log-rsh.sh'
|
|
wrapper.write_text(
|
|
'#!/bin/sh\n'
|
|
'# Log the command line built for the peer, then behave like lsh.sh.\n'
|
|
f'printf \'%s\\n\' "$*" >> {shlex.quote(str(argv_log))}\n'
|
|
f'exec {shlex.quote(str(SRCDIR / "support" / "lsh.sh"))} "$@"\n'
|
|
)
|
|
wrapper.chmod(0o755)
|
|
|
|
rmtree(dst)
|
|
dst.mkdir()
|
|
os.environ['RSYNC_RSH'] = rsh_cmd(str(wrapper))
|
|
run_rsync('-r', '--max-alloc=0', f'--rsync-path={rsync_path_arg()}',
|
|
f'localhost:{src}/', f'{dst}/')
|
|
del os.environ['RSYNC_RSH']
|
|
|
|
if (dst / 'file.txt').read_text() != 'hello\n':
|
|
test_fail('--max-alloc=0 did not copy the file over the remote shell')
|
|
|
|
logged = argv_log.read_text() if argv_log.exists() else ''
|
|
if not logged:
|
|
test_fail('the remote-shell wrapper logged no command line')
|
|
if '--max-alloc=0' not in f' {logged} '.replace('\n', ' '):
|
|
test_fail('--max-alloc=0 was not forwarded verbatim; the peer was sent:\n'
|
|
f'{logged}'
|
|
'\nA resolved number here would be rejected as "too large" by a '
|
|
'peer with a smaller SIZE_MAX.')
|
|
|
|
# --- 3. the upper bound still holds -----------------------------------------
|
|
|
|
# 8192P is one step past SIZE_ARG_MAX (SIZE_MAX/2) on a 64-bit build; on a
|
|
# 32-bit one the P multiplier alone already exceeds it. Either way: too large.
|
|
expect_fail(rsync_argv('--max-alloc=8192P', f'{src}/', f'{dst}/'), 'is too large')
|
|
|
|
# And the min-value message must keep advertising a spelling that works.
|
|
expect_fail(rsync_argv('--max-alloc=1', f'{src}/', f'{dst}/'),
|
|
'or 0 for unlimited')
|
|
|
|
print('max-alloc-zero: 0 is accepted, forwarded verbatim, and the bound holds')
|