rsync - Jul 2014 - question about output of files copied/deleted

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 asd^B^Czxc or asd\#002^Czxc

I was hoping to start with rsync -n, figure out what was
going to be replaced or deleted, archive those files, and
then use the list to do the rsync without the -n but not getting
files that had been updated since the original -n -- but this
ambiguity prevents that from working.

Is there some solution I'm missing?

Otherwise, what's wrong with not encoding the control characters on
output?  I see only one problem, which is that newline characters
would then make it ambiguous whether
asd
zxc
was actually one file or two.
Since there is one character that cannot appear in such a line of
output (for ext4 at least, which is ascii 0), you could replace
newlines with that.  Admittedly not portable...
Perhaps there could be an argument saying how to map file names?

-----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 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 asd^B^Czxc or asd\#002^Czxc
> 
> I was hoping to start with rsync -n, figure out what was going to
> be replaced or deleted, archive those files, and then use the list
> to do the rsync without the -n but not getting files that had been
> updated since the original -n -- but this ambiguity prevents that
> from working.
> 
> Is there some solution I'm missing?
> 
> Otherwise, what's wrong with not encoding the control characters
> on output?  I see only one problem, which is that newline
> characters would then make it ambiguous whether asd zxc was
> actually one file or two. Since there is one character that cannot
> appear in such a line of output (for ext4 at least, which is ascii
> 0), you could replace newlines with that.  Admittedly not
> portable... Perhaps there could be an argument saying how to map
> file names?
> 
- -- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			http://www.sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlPHMOoACgkQVKC1jlbQAQf56QCg9vUotwtVcuqTFc1u3FdW9iJ9
TY0An3tUDfPyRx7QL+0sngKY3RwxhSlL
=Gohd
-----END PGP SIGNATURE-----

On Wed, Jul 16, 2014 at 6:40 PM, Don Cohen <don-rsync at isis.cs3-inc.com>
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 encodes the backslash, so there
is never an ambiguity in replacing \#NNN sequences in the output of
filenames. Only full 5-char sequences are affected that way, so the
decoding rule is as simple as:

  s/\\#(\d\d\d)/ chr(oct($1)) /eg;

..wayne..
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20140716/ad051c0f/attachment.html>