error rsync'ing links of the form ../xxx

[Gary Aviv]

On Mon, 1 May 2006, Wayne Davison wrote:

> On Sat, Apr 29, 2006 at 01:48:28PM -0400, Gary Aviv wrote:
>> However, at the destination the .. is missing. for example
>> the link "../python/compile_plan.py" becomes "python/compile_plan.py"
>> at the destination.
>
> Is your daemon running without chroot?  I just did a test, and rsync's
> symlink sanitizing is getting rid of the leading "../", even when the
> destination would not be outside the top directory of the module.  This
> erroneous behavior has been going on as far back as I checked (which was
> 2.5.7), so it would appear that most people have "use chroot = yes"
> enabled in their daemons.  I'll check into fixing this.
>
> Thanks for the report,
>
> ..wayne..
>

Thanks for your response.

Indeed, my daemon does not have chroot set. It is a non-privileged
daemon so, in fact, cannot chroot. It is also running on a
non-privileged port.

The bug notwithstanding, is sanitizing really required when the
destination is outside the top directory of the module? The symbolic
link itself (the file being transfered) is not outside. It is the
resolution that is. In fact, even if the link is invalid
it should be transfered.

But in any case, I think rsync should either transfer
the symbolic link verbatim or report an error and not
do the transfer at all. Changing the destination silently
is not what anyone would expect.

Thanks,

Gary Aviv

This e-mail and any attachments are confidential and may also be legally privileged and/or copyright material of Intec Telecom Systems PLC (or its affiliated companies). If you are not an intended or authorised recipient of this e-mail or have received it in error, please delete it immediately and notify the sender by e-mail. In such a case, reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. 

Intec Telecom Systems PLC does not represent or warrant that an attachment hereto is free from computer viruses or other defects. The opinions expressed in this e-mail and any attachments may be those of the author and are not necessarily those of Intec Telecom Systems PLC.