Options (--partial, --partial-dir) in rsync don't work as I would expect

I have been trying to figure out how to resume partial transfers in rsync (on Windows, using cygwin) without using the --inplace option.

I see that rsync creates "partial" files in the destination directory with names like .[filename].2dxZ1a, and so, in my understanding, if I used the --partial option, rsync would see a file like this and resume the transfer to this file. But, I'm finding that if I use the --partial option and the rsync process ends, then when I start the rsync command again, it deletes those partial files. Perhaps this option on works on a brief transfer interruption, but not when the process ends and starts over.

In addition to this option, I actually liked the --partial-dir option, expecting that if I specifiy --partial-dir=".rsync" (with or without the surrounding quotes), rsync would create the directory .rsync in the destination directory and transfer the files to [dir]/.rsync, moving them to [dir] once the transfer finished (and deleting [dir]/.rsync once it no longer needed it). But, it seems like rsync is completely ignoring that option and just creating its temporary files in the destination directory like normal (and deleting them on re-start).

So, I'm wondering: am I doing something wrong or do I just not understand those options correctly?

My command is: rsync -rt --log-file="rsync.log" --partial-dir=".rsync" --del rsync://rsync-server:port/module/ /cygdrive/local/path/


I was launching this command from the Windows Task Scheduler. When I took the command and ran it from a console (command prompt), the options worked as they should*.

The only difference between the execution of the commands happened when I tried to end them. In the console, pressing Ctrl+C, rsync ended with the error

rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at ...

In the Windows Task Scheduler, right-clicking the running task and selecting End resulted in the error

rsync: read error: Connection reset by peer (104)

So, I can only assume that the way the Windows Task Scheduler ends a process differs from the way rsync expects to end*, and this makes rsync end without doing its exiting routines.


* - I found more about the way --partial and --partial-dir work.

With --partial, rsync creates a temporary file like I saw, but when rsync ends (in an expected way), it renames that temporary file to the regular filename (e.g. renames .[filename].2dxZ1a to [filename]) and then makes a copy of the partial file to a new temp file on the next run (e.g. copies [filename] to .[filename].34cae2).

With --partial-dir, rsync fills the temporary file, then on close, moves the temporary file into the directory you specify as the regular filename (e.g. renames .[filename].2dxZ1a to [partial-dir]/[filename]). Then, on the next run, it copies the file from [partial-dir] to a new temporary file in the destination directory.


Seems like you have the right ideas, but without knowing your whole command it's impossible to tell. For me these options work like expected when I kill rsync (with ctrl-C) and restart it (GNU/Linux with rsync 3.0.6). One thing to keep is that if you use --wholefile or any option that implies --wholefile (see the rsync man page), then --partial(-dir) won't work and you might see the symptoms you describe. Also, if it cannot find or create the directory specified in --partial-dir, then it will silently ignore it. Another possibility is that --partial actually works for you, but you can't tell and think it starts over, even though it does not - I would expect it to delete the temporary files once it has completed the transfer and updated the actual file. You can monitor this using --progress - it will start at 0%, but then jump very quickly to whatever percentage was already transferred and continue from there. For smaller files the progress may be too quick to see much, so try with something larger (100 MB or more, depending on connection speed to the destination). Hope this helps. Edit: I found that --partial-dir seems to create a temporary file in the destination directory during the transfer, just as with --partial. Only when the transfer dies it moves that to the partial files directory you specified, so initially it seems like it's no different than --partial.