I have been using an rsyncd.conf file with a gid value that contains spaces.
This worked fine until rsync got updated to v3.1.0 and I started getting
invalid gid messages specifying the first word of the gid name as the gid that
could not be found.
Having done some reading on the new funct
https://bugzilla.samba.org/show_bug.cgi?id=10719
Summary: Error with cached effective process gid
Product: rsync
Version: 3.1.1
Platform: x64
OS/Version: FreeBSD
Status: NEW
Severity: major
Priority: P5
Com
On 6/26/2014 5:36 PM, samba-b...@samba.org wrote:
https://bugzilla.samba.org/show_bug.cgi?id=10675
Summary: rsyncing >2GB file onto fat32 partition should fail
earlier
Product: rsync
Version: 3.1.0
Platform: x86
OS/Vers
It seems to me that this output would be more useful if it
were possible to uniquely translate a line of output back into
a file path.
Right now that's not possible due to the control character encoding.
An output line like
asd\#002\#003zxc
could either mean a file of that name or
asd^B\#003zxc or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The solution you are missing is that rsync can archive files itself
using either --link-dest or --backup depending on whether you want a
complete tree in the archive or not.
On 07/16/2014 09:40 PM, Don Cohen wrote:
>
> It seems to me that this output
On Wed, Jul 16, 2014 at 6:40 PM, Don Cohen
wrote:
> An output line like asd\#002\#003zxc could either mean a file of that name
> or asd^B\#003zxc or asd^B^Czxc or asd\#002^Czxc
>
Did you test that theory? Give it a try and you'll discover that \#
followed by 3 digits in a filename always encode
> An output line like asd\#002\#003zxc could either mean a file of
> that name or asd^B\#003zxc or asd^B^Czxc or asd\#002^Czxc
Did you test that theory? Give it a try and you'll discover that \#
followed by 3 digits in a filename always encodes the backslash, so
there is never an ambig