There is a new patch named "delete-during.diff" in the CVS "patches" dir. This patch adds the ability for rsync to incrementally delete files in each directory during the normal course of the transfer rather than doing a separate delete scan either before or after the transfer. The patch renames the current --delete option into --delete-before and makes --delete behave in the delete-during style. I'm debating whether we actually need a --delete-during option -- I'm currently leaning towards leaving it out, so it's not documented as existing at the moment. I've done some simple testing (including both with and without the --relative option) and it seems to work fine so far. Comments? How do people feel about making the --delete-during behavior the default --delete algorithm? I think it will be much more efficient (and less prone to timeouts), so having it as the default is the best choice. The patch applies to (and comes with) the CVS version, and is present in the latest "nightly" tar file (available from the web site). ..wayne..
Wayne, I haven't (yet) given this a try but it sounds like a very reasonable thing to do. --delete-before is still useful in those cases where you may be tight on diskspace. But the default behaviour should be the most efficient one, so I agree with making this patch be the default --delete. On a related note, don't you think it's time to start making candidate releases for 2.6.4? It's been a while... -- Alberto> There is a new patch named "delete-during.diff" in the CVS "patches" > dir. This patch adds the ability for rsync to incrementally delete > files in each directory during the normal course of the transfer rather > than doing a separate delete scan either before or after the transfer. > The patch renames the current --delete option into --delete-before and > makes --delete behave in the delete-during style. I'm debating whether > we actually need a --delete-during option -- I'm currently leaning > towards leaving it out, so it's not documented as existing at the > moment. I've done some simple testing (including both with and without > the --relative option) and it seems to work fine so far. > > Comments? How do people feel about making the --delete-during behavior > the default --delete algorithm? I think it will be much more efficient > (and less prone to timeouts), so having it as the default is the best > choice. > > The patch applies to (and comes with) the CVS version, and is present in > the latest "nightly" tar file (available from the web site). > > ..wayne..******************************************************************** Alberto Accomazzi aaccomazzi(at)cfa harvard edu NASA Astrophysics Data System ads.harvard.edu Harvard-Smithsonian Center for Astrophysics www.cfa.harvard.edu 60 Garden St, MS 31, Cambridge, MA 02138, USA ********************************************************************
On Thu, 20 Jan 2005 18:28:43 -0800, Wayne Davison wrote:> Comments? How do people feel about making the --delete-during behavior > the default --delete algorithm? I think it will be much more efficient > (and less prone to timeouts), so having it as the default is the best > choice.This sounds quite helpful. How does this behave in the event of a read error on the source? The desired behavior from my standpoint would be to disable deletion of files in the current directory, but continue deleting files in other directories. -- Steve
On Fri, 21 Jan 2005 09:55:25 -0800, Steve Bonds <knnf6cy7w001@sneakemail.com> wrote:> On Thu, 20 Jan 2005 18:28:43 -0800, Wayne Davison wrote: > > > Comments? How do people feel about making the --delete-during behavior > > the default --delete algorithm? I think it will be much more efficient > > (and less prone to timeouts), so having it as the default is the best > > choice. > > This sounds quite helpful. How does this behave in the event of a > read error on the source? The desired behavior from my standpoint > would be to disable deletion of files in the current directory, but > continue deleting files in other directories. >just my .02 - but having it delete after the fact is nice in the sense if something dies mid-stream it doesnt screw up your backup (if you do things based on dates or incremental automated backups, etc)> -- Steve > -- > To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync > Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html >-- ---------------------------------- please respond to the list .. if you need to contact me direct cgmckeever is the account prupref.com is the domain <A href="http://www.prupref.com">Simply Chicago Real Estate</A>
On Thu, 20 Jan 2005, Wayne Davison <wayned@samba.org> wrote:> > Comments? How do people feel about making the --delete-during behavior > the default --delete algorithm? I think it will be much more efficient > (and less prone to timeouts), so having it as the default is the best > choice.I agree that it is more efficient. Having this capability is very nice. Users who expect --delete to act before file transfers and want it that way to minimize the chance of rsync filling up the disk might be very surprised at this new behavior. A change in default behavior (when it's not a security fix) can be upsetting to those who depend upon it. But if nobody on this list sees any problem with that, then go for it. -- John Van Essen Univ of MN Alumnus <vanes002@umn.edu>
Yes, I could not agree more. This should be the default behaviour, especially if it can shorten the total time required to sync two disparate file systems. Jeff Yana -----Original Message----- From: John Van Essen <vanes002@umn.edu> Sent: Jan 24, 2005 1:26 AM To: wayned@samba.org, rsync@lists.samba.org Subject: Re: Potential new option: --delete-during On Thu, 20 Jan 2005, Wayne Davison <wayned@samba.org> wrote:> > Comments? How do people feel about making the --delete-during behavior > the default --delete algorithm? I think it will be much more efficient > (and less prone to timeouts), so having it as the default is the best > choice.I agree that it is more efficient. Having this capability is very nice. Users who expect --delete to act before file transfers and want it that way to minimize the chance of rsync filling up the disk might be very surprised at this new behavior. A change in default behavior (when it's not a security fix) can be upsetting to those who depend upon it. But if nobody on this list sees any problem with that, then go for it. -- John Van Essen Univ of MN Alumnus <vanes002@umn.edu> -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html