undefined | Better HN

0 pointstheamk7y ago0 comments

But you still have --delete there, and -u won't affect it. So if you create a local file, it will be deleted (it might stay if by chance it was created during second rsync, but this is not guaranteed).

And the same deletion applies to network errors -- if ssh fails, then newly created files would get deleted.

That said, I agree that -u options does makes it less likely that files get overwritten. This option approach a some caveats, however -- archive extraction will mess the modification time, symlinks and directories are not handled properly. Still, regular IDE editing will work.

Still not sure how is it better than unison though :)

0 comments

1 comments · 1 top-level

headgasket7y ago

Good thinking. You are right that there's a short window between the 2 rsyncs that allows for a newly-created file being created at say the remote end just after (or maybe during? --would need to test) the remote-local rsync that would get deleted by the subsequent local-remote rsync call.

Since there's no lock or anything this vanishing new file just after creation is a possibility. I just wrote this yesterday, I'll be using it extensively, I'll see how annoying this is, and if there's something to do about it.

As a side note, ssh failure has not been a problem (yet), since the script does the same strategy when starting up. In fact I kill and restart this script a lot. I havent played with archive extraction, this is mainly for source code editing.

edit

It would seem that a small modification to the --delete behaviour of rsync to only delete files at the other end that are older than say 30 seconds would handle this edge case. I'll see how annoying it is and if it warrants the time to investigate this.

j / k navigate · click thread line to collapse