Perhaps, all that I need is a "--delete-before-update" option that just unlinks the file before it starts to write the temp file. Then we avoid the possible issues that you raised. I can still see a case where --direct-write may be useful (read-write file in a read-only dir), but this is probably not a common situation, and I don't want to tackle those issues yet.
-don Dave Dykstra wrote: > Oh boy, I think you're getting into quite a can of worms there. > > At a minimum this option should imply the --partial option because if the > operation is aborted the file will be left partially transferred. Note > that if you're trying to use the rsync rolling checksum algorithm to > minimize bandwidth that if a transfer is interrupted all the previous > data will be lost so there will be less data to compare against when the > transfer is retried. > > Next, keep in mind that the receiving side of an rsync transfer uses two > independent processes, one for generating checksums and one for creating > files. I'm not knowledgable enough to know whether or not the creating files > operation is guaranteed to begin only after the checksum generation is > completed on each file, but if it isn't then overwriting a file could be > a big problem. Have you tried transferring any very large files? > > I'm surprised you didn't need to do anything to finish_transfer to keep > the robust_rename from returning an error. > > The last thing that comes to mind is that overwriting files that are open > by another process, such as a running executable, can be a problem. An > unlink/rename works much better for that. > > I'm sure there are more issues too. > > - Dave Dykstra