3 ms·

(author here) Hey thanks for the scrutiny! I'm using the -u option in rsync, preventing overwriting newer changes. So in your described case, it will signal a c

(author here) Hey thanks for the scrutiny! I'm using the -u option in rsync, preventing overwriting newer changes. So in your described case, it will signal a change remote (a lot of changes, but collapsed every 3 seconds) sync remote-local first then local-remote, both with the u option, so not updating if there's a newer version at the other end. No POOF, unless I'm mistaken. Cheers! edit for clarity The trick is every sync step is with -u (not replacing updated files) and done again in the other direction before restarting the watch.

theamk 8y ago
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 :)
- headgasket 8y 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.

theamk 8y ago

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 :)

headgasket 8y 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.