On Thu, Sep 15, 2005 at 10:15:51AM -0700, Wayne Davison wrote:
> Attached is a patch that I think effects the change of using link()
> instead of rename() when possible.
That patch had a couple problems with dealing with boundary conditions
(such as cross-device cases and a filesystem that doesn't
On Thu, Sep 15, 2005 at 08:49:33AM -0700, Wayne Davison wrote:
> (At least, that's all the side-effects I can think of off the top of
> my head.)
At least one more was that backing up a directory without a --backup-dir
still requires using rename().
Attached is a patch that I think effects the ch
On Thu, Sep 15, 2005 at 10:38:04AM -0400, Dave Mielke wrote:
> The only change, therefore, should be to replace the first rename()
> with link(). Since both yield EXDEV, I doubt any more complex change
> is necessary.
It's more complex than that. If the temp file is not in a position
where it can
[quoted lines by Dave Mielke on 2005/09/15 at 10:09 -0400]
>[quoted lines by Chris Shoemaker on 2005/09/15 at 09:59 -0400]
>
>>what about when backup-dir is not on same filesystem
>>as original? link will give EXDEV, I think.
>
>Then, as I see it, rsync should go back to using rename but generate
[quoted lines by Chris Shoemaker on 2005/09/15 at 09:59 -0400]
>what about when backup-dir is not on same filesystem
>as original? link will give EXDEV, I think.
Then, as I see it, rsync should go back to using rename but generate a warning.
--
Dave Mielke | 2213 Fox Crescent | I bel
On Thu, Sep 15, 2005 at 08:45:00AM -0400, Dave Mielke wrote:
> When using --backup, the sequence (as monitored by strace) is:
>
>rename("/path/to/", "/")
>rename("/path/to/..xx", "/path/to/")
>
> This, of course, leaves a momentary window wherein can't be found.
> Might
> it be pos
When using --backup, the sequence (as monitored by strace) is:
rename("/path/to/", "/")
rename("/path/to/..xx", "/path/to/")
This, of course, leaves a momentary window wherein can't be found. Might
it be possible to replace the first rename() with link() instead? This, of
course, coul
