[dajiaohuang]

Problem

Two README instructions do not match the shipped scripts:

• The batch example uses --max-retries=3. osync-batch.sh recognizes --max-runs, so the documented option is forwarded to osync.sh, rejected as unknown, and the configuration fails instead of syncing.
• The manual service setup places osync.sh in /usr/bin/local, but the shipped systemd unit and InitV script look in /usr/local/bin (also the installer destination).

Change

Use --max-runs=3, describe it as up to three total runs per configuration rather than three retries, and correct the manual binary destination. README only; no generated program files changed.

Validation

• Ran the real batch script with a small local configuration: the documented --max-retries=3 invocation failed with the unknown-option error; --max-runs=3 completed successfully.
• Ran local quick/config sync with tiny text fixtures: bidirectional transfer, spaces, dry run, overwrite backups, soft deletion, exclusion, and symlink preservation/following.
• Confirmed the corrected binary destination against dev/common_install.sh, osync-srv, and osync-srv@.service.
• git diff --check passed.

All execution used isolated synthetic local trees. Did not run privileged full suite, SSH/remote sync, monitor services, or the OS matrix; no installer/service changes are involved.

[deajan]

Proofreading done. Makes sense ;)
Thank you.

[deajan]

Yet there's something off:

allowing up to 3 runs per configuration if the whole sequential run took less than 2 hours, use:

--max-runs is designed to relaunch failed jobs N times, so the wording you made is incorrect.

[dajiaohuang]

Thanks for flagging this. I checked the merged-head implementation: MAX_RUNS=3 is documented in osync-batch.sh as the number of total runs, Batch starts with runs=1, loops while runs <= MAX_RUNS, and increments after each pass. Failed configurations alone enter the next pass, so this permits up to three runs total (the initial run plus at most two retries), subject to the time limit. The README wording is intended to describe that current behavior. If you meant the option should instead permit N retries after the initial attempt, that would be a behavior change rather than a documentation correction.

[deajan]

Indeed, only failed runs are retried
When I read "allowing up to 3 runs per configuration if the whole sequential run took less than 2 hours", I understand that it would run 3 sucessful runs of the same config in 2 hours, which is not the case.