populate file: check the .rsync-filter files that really apply

rsync reads .rsync-filter files in the directories above a source as
well, and their rules apply to the transfer.  The check for files that
rsync 3.5.0 and later can't read only starts if the source itself
contains one, so a subdirectory of a repository with a filter file at
its top gets synced without it, silently.  The check also starts for
filter files above the source.

The check's dry run is the transfer it stands for, as far as filtering
goes:

- It gets the source's exclude and filters, so it doesn't enter
  directories the transfer skips.
- It doesn't run for transfers that apply no .rsync-filter files, i.e.
  uploads of flakes and patches.
- A filter file the user may not read anyway doesn't count: rsync fails
  on its own when it gets to transfer that file, and --insecure-links
  changes nothing about it.
- rsync prints bytes it takes for unprintable as \#ooo, which depends on
  the locale.  File names get decoded before checking that they exist, so
  files below, e.g., directories with umlauts in their names don't pass
  for missing in the C locale.
- If rsync doesn't tell which filter files it reads at all, populate
  warns that it can't tell either.

The README mentions that --insecure-links also affects the way to the
target path on local targets, and that only rsync 3.5.0 ignores filter
files below directories that may be entered but not read.

Phases of scenarios can set environment variables for populate.  New
file scenarios sync a subdirectory whose filter file is above it, and a
source with a filter file below a directory with an umlaut in its name,
in the C locale.

0 files changed, 0 insertions, 0 deletions