[Bug 11656] Escaping broken with --files-from

2015-12-30 Thread samba-bugs
https://bugzilla.samba.org/show_bug.cgi?id=11656 --- Comment #9 from Gennady Uraltsev --- I looked through the source code and it seems that whatever is happening is going bad in the function static void filtered_fwrite in log.c in particular the line #134 fprintf(f, "\\#%03o", *(uchar*)s); i

[Bug 11656] Escaping broken with --files-from

2015-12-30 Thread samba-bugs
https://bugzilla.samba.org/show_bug.cgi?id=11656 --- Comment #8 from Kevin Korb --- I was not offended. I was just trying to establish your use case and offer possible alternative methods of accomplishing it while not actually being an rsync dev. Wayne is really the only person who can say "Yep

[Bug 11656] Escaping broken with --files-from

2015-12-30 Thread samba-bugs
https://bugzilla.samba.org/show_bug.cgi?id=11656 --- Comment #7 from Gennady Uraltsev --- Furthermore consider this test case: in addition to what we did before create the file with the actual name aaa\#012bbb by doing touch 'src/aaa\#012bbb' then $ rsync -n --itemize-changes -a src/* dst/ >

[Bug 11656] Escaping broken with --files-from

2015-12-30 Thread samba-bugs
https://bugzilla.samba.org/show_bug.cgi?id=11656 --- Comment #6 from Gennady Uraltsev --- I hope I am not upsetting anyone. Maybe I wasn't clear: --itemize-changes is half the problem. Maybe I should post another bug. In the situation I described $ rsync -n --itemize-changes -a src/* dst/ give

[Bug 11656] Escaping broken with --files-from

2015-12-30 Thread samba-bugs
https://bugzilla.samba.org/show_bug.cgi?id=11656 --- Comment #5 from Kevin Korb --- I would say that if your goal is to make an editable list to be run through rsync later you would be a lot better off with an --itemize-changes list and a script to reformat it after editing. I don't know about y

[Bug 11656] Escaping broken with --files-from

2015-12-30 Thread samba-bugs
https://bugzilla.samba.org/show_bug.cgi?id=11656 --- Comment #4 from Gennady Uraltsev --- Well, imagine a poor mans replacement for batch files. We want to generate a list of operations, maybe edit it by hand (a batch file is binary...) and then feed it back to rsync. Or maybe do a dry run, look

[Bug 11656] Escaping broken with --files-from

2015-12-30 Thread samba-bugs
https://bugzilla.samba.org/show_bug.cgi?id=11656 --- Comment #3 from Kevin Korb --- I am not sure what exactly the point of using an rsync -n to feed an rsync --files-from would be. The --files-from option is really designed to be fed from find which has a -print0 option which will format things

[Bug 11656] Escaping broken with --files-from

2015-12-30 Thread samba-bugs
https://bugzilla.samba.org/show_bug.cgi?id=11656 --- Comment #2 from Gennady Uraltsev --- Actually this doesn't help. $ mkdir src; mkdir dst; touch src/"$(echo -e 'foo\nbar')" $ rsync -n --out-format='%n' src/* dst/| tr '\n' '\0' | rsync -v --from0 --files-from=- src/ dst still fails completel

[Bug 11656] Escaping broken with --files-from

2015-12-30 Thread samba-bugs
https://bugzilla.samba.org/show_bug.cgi?id=11656 --- Comment #1 from Kevin Korb --- This is what --from0 is for. -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change op

Re: strange behaviour when using (conflicting) options -q --progress

2015-12-30 Thread Paul Slootman
On Wed 30 Dec 2015, Paul Slootman wrote: > -q seems to override -v completely, but when combined with --progress, > a single newline is output when there are no updates transferred; but if > a file *was* updated nothing at all is output. > > It seems that there might be some short-circuited code

strange behaviour when using (conflicting) options -q --progress

2015-12-30 Thread Paul Slootman
-q seems to override -v completely, but when combined with --progress, a single newline is output when there are no updates transferred; but if a file *was* updated nothing at all is output. It seems that there might be some short-circuited code when nothing is trasferred, but that a check for qui

minor patch for manpage

2015-12-30 Thread Paul Slootman
The description for --compress-level=NUM does not give any indication what values are permitted for NUM. Paul --- ./rsync.yo.orig 2015-12-30 11:47:24.180646652 +0100 +++ ./rsync.yo 2015-12-30 11:47:27.477198899 +0100 @@ -1907,7 +1907,9 @@ that will not be compressed. dit(bf(--compress-le