Problem retrieving file starting with '-' character from top of repository
tim at ripe.net
Thu Dec 23 02:13:14 MST 2010
On 12/22/10 6:08 PM, Wayne Davison wrote:
> On Wed, Dec 22, 2010 at 1:53 AM, Tim Bruijnzeels <tim at ripe.net
> <mailto:tim at ripe.net>> wrote:
> There seems to be a problem when trying to retrieve a file that
> starts with a '-' character, if it lives in the top of an rsync
> If the file gets requested by name on the command-line, then popt will
> interpret it as an option, which will cause a problem. I don't see how
> the daemon protocol you cited could fail, though, since it always sends
> the file names over the daemon protocol. For a non-daemon file request,
> the issue can be avoided by requesting the name with a dot-slash at the
> start (or using --protect-args in newer rsync versions). For instance:
> rsync -aiv localhost:./-fails /dest/
first of all I don't know the implementation internals of rsync so I am
sorry if my suspicions are off the ball and/or misleading.
Having said that I do know that - is generally used for options on the
command line so I tried a number of ways to avoid using the character as
such in the first place:
- by using -- to indicate no more arguments
- by using \ to quote the -
- by using ' marks around the URI
- by using ? instead of the - character
- by using * instead of the - character
None of these attempts made a difference. --protect-args when used with
a 3.0.7 command line client did not make a difference either.
Also, this does not explain why it would be safe to say:
rsync://remote-host/repo-base/./-file (which indeed works)
The - is still there so why is it now not seen as an argument?
In any case thank you for the advice to use './' in front of '-' files.
I think I can use this as a general work-around in our client code that
needs to access files directly in remote rsync repositories. Since I
have no way of knowing for sure, without extra work, as a remote client,
where the actual top of the repository is I'd be doing stuff like this
which also works...
I still believe I should not have to worry about this though. I am not
convinced the problem is between my shell and my rsync client, so I
would prefer that my local client and remote server work it out between
More information about the rsync