search for: send_deflated_token

..., batchfiles, IPv6, 64-bit system inums, 64-bit internal inums : (gdb) b token.c:285 (gdb) condition 1 tx_strm.avail_in != 0 && tx_strm.avail_out == 0 (gdb) run -zI install-disk2.iso 127.0.0.1:/var/tmp/install-disk2.iso so 127.0.0.1:/var/tmp/install-disk2.iso Breakpoint 1, send_deflated_token (f=7, token=2731, buf=0x8099150, offset=44744704, nb=0, toklen=16384) : (gdb) p tx_strm.avail_in $1 = 16384 (gdb) p tx_strm.avail_out $2 = 0 (gdb) p tx_strm.total_in $3 = 44744704 (gdb) p tx_strm.total_out $4 = 44758356 (gdb) n 286 rprintf(FERROR, "deflate on...

...hen the first file read has a suffix in the skip list. Looking at the set_compression function in token.c, I see that the compression_level variable is set to 0 when a file with a suffix in the skip list is encountered, but that variable appears to only be read once during the initial execution of send_deflated_token. Am I misunderstanding the intent of the --skip-compress option? Thank you for your consideration, Kit -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20160825/d97b3bf6/attachment.html>

...y to force a comparison. The real world scenario would be the sync of a truecrypt container. This transfer aborts with a timeout. The reason is that during the hash_search phase no packets are sent to the peer. If I omit the --compress option, tokens are sent regularly, preventing the timeout, but send_deflated_token() seems to collect an hours worth of responses before sending them out. Flushing them on a regular basis to prevent a timeout would be good. -Arne

...match.c:219: warning: unsigned int format, uint32_t arg (arg 5) syscall.c: In function `do_mkstemp': syscall.c:230: warning: implicit declaration of function `setmode' io.c: In function `read_msg_fd': io.c:413: warning: int format, long unsigned int arg (arg 4) token.c: In function `send_deflated_token': token.c:377: warning: int format, int32_t arg (arg 3) token.c:418: warning: int format, int32_t arg (arg 3) token.c: In function `recv_deflated_token': token.c:496: warning: int format, int32_t arg (arg 4) token.c:546: warning: int format, int32_t arg (arg 4) acls.c: In function `pack_sm...

...2 n, r; + + /* initialization */ + if (!comp_init_done) { + + zstd_cctx = ZSTD_createCCtx(); + if (!zstd_cctx) { + rprintf(FERROR, "compression init failed\n"); + exit_cleanup(RERR_PROTOCOL); + } + + obuf = new_array(char, MAX_DATA_COUNT + 2); + if (!obuf) + out_of_memory("send_deflated_token"); + + ZSTD_CCtx_setParameter(zstd_cctx, ZSTD_c_compressionLevel, + def_compress_level); + zstd_out_buff.dst = obuf + 2; + + comp_init_done = 1; + } + + if (last_token == -1) { + last_run_end = 0; + run_start = token; + flush_pending = 0; + } else if (last_token == -2) { + run...

...ap_struct->status. It is caller's responsibility to check the status and handle this condition appropriately. It is probably OK to ignore this when we are generating checksums (as it might lead to a false mismatch, resulting in transfer of a non matching block) But in context of transfer (send_deflated_token()) when this error is ignored it leads to silent data corruption for receiver. Possible solutions are to log errors and disconnect such connection, or retry till timeout happens. No point in giving user a false impression that xfr is successful. Request dev to look at it with priority. Cheers,...

Hi, When using rsync-3.0.2 through 3.0.5, I get this error on a large dataset syncing from machine-a to machine-b: $ /bin/rsync -aHSz /local/. machine-b:/local/. invalid len passed to map_ptr: -1737287498 rsync error: error in file IO (code 11) at fileio.c(188) [sender=3.0.5] This happens no matter which side initiates the connection, so this fails in the same way: $ /bin/rsync -aHSz

...nt) ); } } + + return l; } /* Flag bytes in compressed stream are encoded as follows: */ @@ -137,17 +144,18 @@ /* Output buffer */ static char *obuf; -/* Send a deflated token */ -static void +/* Send a deflated token. Returns size of data sent (before compression). */ +static int send_deflated_token(int f, int token, struct map_struct *buf, OFF_T offset, int nb, int toklen) { int n, r; static int init_done, flush_pending; extern int write_batch; /* dw */ char temp_byte; /* dw */ + int data_read = 0; if (last_token == -1) { /* initialization */ if (!init_done) { @@...

https://bugzilla.samba.org/show_bug.cgi?id=6916 Summary: Avoid bundling a modified zlib Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned at samba.org ReportedBy: matt at mattmccutchen.net

> Just curious: what about the rsync+ patch? Thanks for the reminder. I've just committed Jos's rsync+ patch onto the "branch_mbp_rsyncplus_merge" branch. If it works OK and nobody screams I will move it across onto the main tree tomorrow or Wednesday. I see the patch doesn't add documentation about the new options to the man page, so we should fix that in the future.