Looking for a list of rsync error outputs
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I'm setting up at text filter for some of my routines. If I had a list of errors and other messages, as they are displayed in the output, this would make my filtered outputs a lot more versatile.
So far I have these patterns:
^ERROR:
^rsync error:
^skipping non-regular file
Is there documentation or notes on this anywhere?
rsync
add a comment |Â
up vote
1
down vote
favorite
I'm setting up at text filter for some of my routines. If I had a list of errors and other messages, as they are displayed in the output, this would make my filtered outputs a lot more versatile.
So far I have these patterns:
^ERROR:
^rsync error:
^skipping non-regular file
Is there documentation or notes on this anywhere?
rsync
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I'm setting up at text filter for some of my routines. If I had a list of errors and other messages, as they are displayed in the output, this would make my filtered outputs a lot more versatile.
So far I have these patterns:
^ERROR:
^rsync error:
^skipping non-regular file
Is there documentation or notes on this anywhere?
rsync
I'm setting up at text filter for some of my routines. If I had a list of errors and other messages, as they are displayed in the output, this would make my filtered outputs a lot more versatile.
So far I have these patterns:
^ERROR:
^rsync error:
^skipping non-regular file
Is there documentation or notes on this anywhere?
rsync
asked Oct 27 '17 at 18:25
Lumify
1217
1217
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
I think you'll not find a nice, tidy answer to this question. I did a brute-force search for strings that look like errors in the source code and there is little in the way of organization or patterns that I can see. For example, this is a tiny sampling of overall errors that I found with a simple grep
for FERROR
(I assume this is a file descriptor for stderr or equivalent)...
"ABORTING due to unsafe pathname from sender: %sn"
"All source args must come from the same machine.n"
"Batch file %s open error"
"Daemon option(s) used without --daemon.n"
"ERROR: Skipping sender remove for changed file: %sn"
"ERROR: buffer overflow in %s [%s]n"
"FATAL I/O ERROR: dying to avoid a --delete-%s issue with a pre-3.0.7 receiver.n"
"Failed to close"
"Hlink node data for %d already has path=%s (%s)n"
"If arg is a remote file/dir, prefix it with a colon (:).n"
"Impossible error in external-zlib code (1).n"
"Integer overflow: attempted 64-bit offsetn"
"Internal hashtable error: illegal key supplied!n"
"Invalid ID number: %sn"
"Overflow in read_varint()n"
"Overflow in read_varlong()n"
"Unexpected remote arg: %sn"
"Unknown filter rule: `%s'n"
"[%s] could not find xattr #%d for %sn"
"[%s] internal abbrev error on %s (%s, len=%ld)!n"
"rsync error: %s (code %d) at %s(%d) [%s=%s]n"
"rsync: did not see server greetingn"
This is just a small subset of the messages that I found with grep
and even that whole set is just a subset of the total overall as a simple grep doesn't catch, for example, messages that aren't on the same line as FERROR
(and there are plenty of those).
It looks like I'll have to write things another way.
â Lumify
Oct 27 '17 at 19:12
Yeah. Frankly, the situation is chaos...not uncommon with code bases that go way back.
â B Layer
Oct 27 '17 at 19:14
add a comment |Â
up vote
0
down vote
Any successful file transfer should have its transfer status in the form of something like >f..T......
so you could figure out a regex for that and perform a reverse match.
Additionally, rsync's log output format is highly configurable, so you may be able to get what you want by changing that.
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
I think you'll not find a nice, tidy answer to this question. I did a brute-force search for strings that look like errors in the source code and there is little in the way of organization or patterns that I can see. For example, this is a tiny sampling of overall errors that I found with a simple grep
for FERROR
(I assume this is a file descriptor for stderr or equivalent)...
"ABORTING due to unsafe pathname from sender: %sn"
"All source args must come from the same machine.n"
"Batch file %s open error"
"Daemon option(s) used without --daemon.n"
"ERROR: Skipping sender remove for changed file: %sn"
"ERROR: buffer overflow in %s [%s]n"
"FATAL I/O ERROR: dying to avoid a --delete-%s issue with a pre-3.0.7 receiver.n"
"Failed to close"
"Hlink node data for %d already has path=%s (%s)n"
"If arg is a remote file/dir, prefix it with a colon (:).n"
"Impossible error in external-zlib code (1).n"
"Integer overflow: attempted 64-bit offsetn"
"Internal hashtable error: illegal key supplied!n"
"Invalid ID number: %sn"
"Overflow in read_varint()n"
"Overflow in read_varlong()n"
"Unexpected remote arg: %sn"
"Unknown filter rule: `%s'n"
"[%s] could not find xattr #%d for %sn"
"[%s] internal abbrev error on %s (%s, len=%ld)!n"
"rsync error: %s (code %d) at %s(%d) [%s=%s]n"
"rsync: did not see server greetingn"
This is just a small subset of the messages that I found with grep
and even that whole set is just a subset of the total overall as a simple grep doesn't catch, for example, messages that aren't on the same line as FERROR
(and there are plenty of those).
It looks like I'll have to write things another way.
â Lumify
Oct 27 '17 at 19:12
Yeah. Frankly, the situation is chaos...not uncommon with code bases that go way back.
â B Layer
Oct 27 '17 at 19:14
add a comment |Â
up vote
1
down vote
accepted
I think you'll not find a nice, tidy answer to this question. I did a brute-force search for strings that look like errors in the source code and there is little in the way of organization or patterns that I can see. For example, this is a tiny sampling of overall errors that I found with a simple grep
for FERROR
(I assume this is a file descriptor for stderr or equivalent)...
"ABORTING due to unsafe pathname from sender: %sn"
"All source args must come from the same machine.n"
"Batch file %s open error"
"Daemon option(s) used without --daemon.n"
"ERROR: Skipping sender remove for changed file: %sn"
"ERROR: buffer overflow in %s [%s]n"
"FATAL I/O ERROR: dying to avoid a --delete-%s issue with a pre-3.0.7 receiver.n"
"Failed to close"
"Hlink node data for %d already has path=%s (%s)n"
"If arg is a remote file/dir, prefix it with a colon (:).n"
"Impossible error in external-zlib code (1).n"
"Integer overflow: attempted 64-bit offsetn"
"Internal hashtable error: illegal key supplied!n"
"Invalid ID number: %sn"
"Overflow in read_varint()n"
"Overflow in read_varlong()n"
"Unexpected remote arg: %sn"
"Unknown filter rule: `%s'n"
"[%s] could not find xattr #%d for %sn"
"[%s] internal abbrev error on %s (%s, len=%ld)!n"
"rsync error: %s (code %d) at %s(%d) [%s=%s]n"
"rsync: did not see server greetingn"
This is just a small subset of the messages that I found with grep
and even that whole set is just a subset of the total overall as a simple grep doesn't catch, for example, messages that aren't on the same line as FERROR
(and there are plenty of those).
It looks like I'll have to write things another way.
â Lumify
Oct 27 '17 at 19:12
Yeah. Frankly, the situation is chaos...not uncommon with code bases that go way back.
â B Layer
Oct 27 '17 at 19:14
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
I think you'll not find a nice, tidy answer to this question. I did a brute-force search for strings that look like errors in the source code and there is little in the way of organization or patterns that I can see. For example, this is a tiny sampling of overall errors that I found with a simple grep
for FERROR
(I assume this is a file descriptor for stderr or equivalent)...
"ABORTING due to unsafe pathname from sender: %sn"
"All source args must come from the same machine.n"
"Batch file %s open error"
"Daemon option(s) used without --daemon.n"
"ERROR: Skipping sender remove for changed file: %sn"
"ERROR: buffer overflow in %s [%s]n"
"FATAL I/O ERROR: dying to avoid a --delete-%s issue with a pre-3.0.7 receiver.n"
"Failed to close"
"Hlink node data for %d already has path=%s (%s)n"
"If arg is a remote file/dir, prefix it with a colon (:).n"
"Impossible error in external-zlib code (1).n"
"Integer overflow: attempted 64-bit offsetn"
"Internal hashtable error: illegal key supplied!n"
"Invalid ID number: %sn"
"Overflow in read_varint()n"
"Overflow in read_varlong()n"
"Unexpected remote arg: %sn"
"Unknown filter rule: `%s'n"
"[%s] could not find xattr #%d for %sn"
"[%s] internal abbrev error on %s (%s, len=%ld)!n"
"rsync error: %s (code %d) at %s(%d) [%s=%s]n"
"rsync: did not see server greetingn"
This is just a small subset of the messages that I found with grep
and even that whole set is just a subset of the total overall as a simple grep doesn't catch, for example, messages that aren't on the same line as FERROR
(and there are plenty of those).
I think you'll not find a nice, tidy answer to this question. I did a brute-force search for strings that look like errors in the source code and there is little in the way of organization or patterns that I can see. For example, this is a tiny sampling of overall errors that I found with a simple grep
for FERROR
(I assume this is a file descriptor for stderr or equivalent)...
"ABORTING due to unsafe pathname from sender: %sn"
"All source args must come from the same machine.n"
"Batch file %s open error"
"Daemon option(s) used without --daemon.n"
"ERROR: Skipping sender remove for changed file: %sn"
"ERROR: buffer overflow in %s [%s]n"
"FATAL I/O ERROR: dying to avoid a --delete-%s issue with a pre-3.0.7 receiver.n"
"Failed to close"
"Hlink node data for %d already has path=%s (%s)n"
"If arg is a remote file/dir, prefix it with a colon (:).n"
"Impossible error in external-zlib code (1).n"
"Integer overflow: attempted 64-bit offsetn"
"Internal hashtable error: illegal key supplied!n"
"Invalid ID number: %sn"
"Overflow in read_varint()n"
"Overflow in read_varlong()n"
"Unexpected remote arg: %sn"
"Unknown filter rule: `%s'n"
"[%s] could not find xattr #%d for %sn"
"[%s] internal abbrev error on %s (%s, len=%ld)!n"
"rsync error: %s (code %d) at %s(%d) [%s=%s]n"
"rsync: did not see server greetingn"
This is just a small subset of the messages that I found with grep
and even that whole set is just a subset of the total overall as a simple grep doesn't catch, for example, messages that aren't on the same line as FERROR
(and there are plenty of those).
edited Oct 27 '17 at 19:31
answered Oct 27 '17 at 19:06
B Layer
3,9241525
3,9241525
It looks like I'll have to write things another way.
â Lumify
Oct 27 '17 at 19:12
Yeah. Frankly, the situation is chaos...not uncommon with code bases that go way back.
â B Layer
Oct 27 '17 at 19:14
add a comment |Â
It looks like I'll have to write things another way.
â Lumify
Oct 27 '17 at 19:12
Yeah. Frankly, the situation is chaos...not uncommon with code bases that go way back.
â B Layer
Oct 27 '17 at 19:14
It looks like I'll have to write things another way.
â Lumify
Oct 27 '17 at 19:12
It looks like I'll have to write things another way.
â Lumify
Oct 27 '17 at 19:12
Yeah. Frankly, the situation is chaos...not uncommon with code bases that go way back.
â B Layer
Oct 27 '17 at 19:14
Yeah. Frankly, the situation is chaos...not uncommon with code bases that go way back.
â B Layer
Oct 27 '17 at 19:14
add a comment |Â
up vote
0
down vote
Any successful file transfer should have its transfer status in the form of something like >f..T......
so you could figure out a regex for that and perform a reverse match.
Additionally, rsync's log output format is highly configurable, so you may be able to get what you want by changing that.
add a comment |Â
up vote
0
down vote
Any successful file transfer should have its transfer status in the form of something like >f..T......
so you could figure out a regex for that and perform a reverse match.
Additionally, rsync's log output format is highly configurable, so you may be able to get what you want by changing that.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Any successful file transfer should have its transfer status in the form of something like >f..T......
so you could figure out a regex for that and perform a reverse match.
Additionally, rsync's log output format is highly configurable, so you may be able to get what you want by changing that.
Any successful file transfer should have its transfer status in the form of something like >f..T......
so you could figure out a regex for that and perform a reverse match.
Additionally, rsync's log output format is highly configurable, so you may be able to get what you want by changing that.
answered Feb 9 at 15:14
Andy Foster
34425
34425
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f400940%2flooking-for-a-list-of-rsync-error-outputs%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password