[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 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

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 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

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 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

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 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

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/ 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

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/ 
>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

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, 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

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); 

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

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 options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


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-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

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 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

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 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