<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 3/23/2011 2:35 PM, Eric Searcy wrote:
    <blockquote
      cite="mid:AAD9E9A8-33ED-4664-B58A-E81C0F6BA75A@gmail.com"
      type="cite">
      <pre wrap="">On Mar 17, 2011, at 3:37 AM, Dave Howorth wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">Of course that begs the whole question of how to test it ... ?
</pre>
      </blockquote>
      <pre wrap="">
Who needs to test? ;-)

On the "it should be fairly simple" point I believe the last line in default.hist is always the most recent non-branched successful backup (failures don't get logged).  This should automatically allow one to handle things like --image "blahname" backups that don't go into the sort order nicely, and also avoid needing to parse summary.gz logs.

Speaking of branches, maybe you should never delete the last successful backup from any branch?  (each last line from *.hist)</pre>
    </blockquote>
    <br>
    As far as I know, dirvish-expire does not use the hist files, nor do
    I think it really should.&nbsp; It appears to load the summary file which
    contains everything that is stored in the .hist file, but is located
    with the image.&nbsp; I occasionally modify the Expire tag on already run
    backups to extend their lifetime.&nbsp; Mostly I just delete the Expire
    header and I'd hate to see an image get deleted because I forgot to
    update the corresponding .hist entry.&nbsp; The only potential benefit I
    see to the .hist file is that is contains the history of images
    already expired, though I'm not really sure what value that is.<br>
    <br>
    I do think a simple fix need to be made to dirvish-expire to not
    remove the most recent image made when all images have expired.&nbsp;
    Recently I brought an old backup drive into the rotation again, it
    had been sitting idle for more than a year and all images were
    expired.&nbsp; For each vault, it first complained that it could not
    remove the oldest image due to there being no unexpired images, then
    proceeded to delete all more recent images.&nbsp; This meant a lot of
    wasted time in in syncing up the backups as this put it almost two
    full years old in backups for the reference point.&nbsp; I am looking at
    making a patch for this particular case, but I do see merit in
    adding logic so that the most recent image is not deleted by
    default.&nbsp; In most cases it won't be a problem since the backups will
    be run more often then the shortest expiry period, but, especially
    in the case where nothing is unexpired, deleting the newest backup
    is usually not the best option.<br>
    <br>
    <blockquote
      cite="mid:AAD9E9A8-33ED-4664-B58A-E81C0F6BA75A@gmail.com"
      type="cite">
      <pre wrap="">

Eric</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Dirvish mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dirvish@dirvish.org">Dirvish@dirvish.org</a>
<a class="moz-txt-link-freetext" href="http://www.dirvish.org/mailman/listinfo/dirvish">http://www.dirvish.org/mailman/listinfo/dirvish</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Loren M. Lang
<a class="moz-txt-link-abbreviated" href="mailto:lorenl@alzatex.com">lorenl@alzatex.com</a>
<a class="moz-txt-link-freetext" href="http://www.alzatex.com/">http://www.alzatex.com/</a>


Public Key: <a class="moz-txt-link-freetext" href="ftp://ftp.tallye.com/pub/lorenl_pubkey.asc">ftp://ftp.tallye.com/pub/lorenl_pubkey.asc</a>
Fingerprint: 10A0 7AE2 DAF5 4780 888A  3FA4 DCEE BB39 7654 DE5B
</pre>
  </body>
</html>