[Bug 11656] Escaping broken with --files-from
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 completely. The problem is that the escaped string foo\#012bar gets all mangled up. So I think that --from0 doesn't exactly solve the problem. The only way to solve the problem is $ rsync -n --out-format='%n' src/* dst/| tr '\n' '\0'| sed 's/\\#012/\n/' | rsync -v --from0 --files-from=- src/ dst but maybe we could agree that this is needlessly complicated. A more consistent way of dealing with this would be great especially bearing in mind that this failure is not documented... Finally it is still completely unexpected that foo\#012bar gets changed into foo\#134#012bar Anyway the problem with space delimited strings is more as follows. Immagine I want to parse the log file generated with --out-format='%n %h %M %C' in a reliable way by some external program. Without consistent and documented escaping there seems no way to do this. -- 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 options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 11656] Escaping broken with --files-from
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 correctly for --from0. -- 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 options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 11656] Escaping broken with --files-from
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 at it, and then just selectively remove some files. There are many use cases. Apart from that I argue that the inconsistencies in interpreting escape sequences merit fixing. Ok, maybe it is not top priority but there still is no reason why foo\#012bar becomes foo\#134#012bar. -- 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 options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 11656] Escaping broken with --files-from
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 you but I would hate to have to edit a null terminated text file and I would hate to have to go lookup why a file is in the list without the --itemize-changes output. Anyway, I think I am done commenting here and will leave this for Wayne to decide if this is really a bug or a use case problem. -- 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 options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 11656] Escaping broken with --files-from
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/ gives: >f..t.. foo\#012bar with the new line being escaped in a weird way that cannot be effectively fed back into any kind of other program, not even rsync itself! -- 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 options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 11656] Escaping broken with --files-from
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/ >f+ aaa\#134#012bbb >f..t.. foo\#012bar where the escaping in itemize-change of aaa\#012bbb is completely absurd! -- 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 options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 11656] Escaping broken with --files-from
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, that's a bug" or "Nope, that is how I want it to work." -- 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 options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 11656] Escaping broken with --files-from
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); is suspicious. The problem is that #134 is the octal code for the backslash character. -- 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 options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 11656] Escaping broken with --files-from
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 options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
minor patch for manpage
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-level=NUM)) Explicitly set the compression level to use -(see bf(--compress)) instead of letting it default. If NUM is non-zero, +(see bf(--compress)) instead of letting it default. Allowed values for NUM +are between 0 and 9; default when bf(--compress) option is specified is 6. +If NUM is non-zero, the bf(--compress) option is implied. dit(bf(--skip-compress=LIST)) Override the list of file suffixes that will -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
strange behaviour when using (conflicting) options -q --progress
-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 quiet mode is skipped somehow. Paul -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: strange behaviour when using (conflicting) options -q --progress
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 when nothing is > trasferred, but that a check for quiet mode is skipped somehow. The bug report in Debian below may be related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749165 Here the issue is basically that a newline is *missing* after --progress output has been generated. The output basically is: 0 files...^M 400 files...^M 2500 files...^M 4600 files...^Ma1/ a2/ The a1/ part overwrites the " 4600 files..." part partially. perhaps the extraneous newline in my first part is related to this missing newline here? Paul -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html