Chad tripped over this today in prod. He made a change to /a/common/wmf-config/PrivateSettings.php (which is a symlink to /a/common/private/PrivateSettings.php) and then ran sync-file wmf-config/PrivateSettings.php to sync the file with the cluster.
This resulted in an rsync command similar to this running on each cluster host:
sudo -u mwdeploy -n -- /usr/bin/rsync --archive --delete-delay --delay-updates --compress --delete --exclude=/.svn/lock --exclude=/.git/objects --exclude=/.git//objects --exclude=**/cache/l10n/*.cdb --no-perms --include=/wmf-config --include=/wmf-config/PrivateSettings.php --exclude=* tin.eqiad.wmnet::common /usr/local/apache/common-local
Scap is dutifully syncing the file that it was asked to sync, but that file is just a symlink so rsync will only actually sync a symlink and not the contents of the file the symlink points to on tin.
The manual fix that a deployer can use is to run sync-file private/PrivateSettings.php instead to sync the actual file rather than the symlink. This seems error prone to say the least however. Scap should do something (at least emit a warning) when asked to sync a symlink. Ideally it could sync both the symlink and the target file but that may be too much magic.