direct write patch

[Don Mahurin]

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