We use rsync to synchronize files up to a remote host, intending to clear files from the client filesystem once the rsync transfer succeeds. The connection has limited bandwidth (< 1 mbps) and is intermittent (often active only for about 10 minutes at a time, potentially hours between connections), due to connectivity via satellite. The files being transferred are 100-200 megabytes. Since we may have several files queued, the transfers take time and often require several windows of connectivity to complete. We use the following cli flags for this: `--verbose --progress --exclude=".*" --timeout=15 --partial-dir=.partial --partial --recursive --remove-source-files`. I observe that sometimes the transfer of file1 completes successfully, and then the process moves to file2. However, even after transferring file2 for several minutes, file1 remains on the client's filesystem. I've been looking a bit at the rsync code, and I think I have determined that it prioritizes transferring buffered file data over sending control messages (such as the MSG_SUCCESS message that would result in the client side file being deleted). So my suspicion is that it's loading the data buffer with data from file2 and trying to transfer that data. Consequently, the MSG_SUCCESS message is never prioritized as rsync is killed (due to end of network connection) before it can make it through, even though file1 was successfully transferred several minutes earlier. Does this sound right? Are there any outstanding bugs or feature requests that might improve this situation (I searched and couldn't find any)? It seems sensible to prioritize sending MSG_SUCCESS over file data so that this workflow works more reliably. Would that make sense? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20260411/12c075dd/attachment.htm>