Re: code 11: files changed during backup

I think this is an interesting feature, and could use that too.

My two observations:

1 - could dar behave differently if it can seek and if it cannot seek?
Say, the target is a filesystem, it could retry the backup over the
last one, if it is a pipe or a char device, it could do as Lasse
suggests. As the other options (at most x retries and at most y
megabytes), they would be great.

2 - as per extraction, i think it should follow the current behaviour
by default, extracting everything (just spitting warnings about the
unclean ones). Two other switches could change that to 1) ask the user
and 2) ignore them all. This way it will be really backwards
compatible with the scripts written and already distributed.

andre

On 3/13/07, Lasse Kliemann
<lasse-list-dar-discussions-2007-vHKVnW1TcfEx7OB5OnRqRA@public.gmane.org> wrote:
> Hello,
>
> * Denis Corbin writes:
> > Lasse Kliemann wrote:
>
> > > I have got two suggestions how to deal with the situation when a file changes
> > > while being backed up with dar -- I mean the cases where code 11 is returned.
> > > There are two approaches that could both be implemented at the same time:
> > >
> > > 1. If dar encounters a changing file during backup, dar could re-try to
> > > backup this file several times, until it succeeds in getting a clean copy of
> > > it. The number of re-tries (before giving up on that file) could be set using
> > > a command line option.
> >
> > The problem with this first point is that when creating an archive dar
> > cannot skip back to overwrite data (dar must transparently handle the
> > case where the archive is output to standard output or named pipe, two
> > devices that do not support seeking). Thus this first point is not
> > possible to implement.
>
> I had not thought about that. However, there is a variation of my idea that
> can still be realized. As suggested below, a file that could not be copied
> into the archive cleanly shall be marked as 'unclean'. As you explained, we
> cannot remove an unclean file from the archive. Still, we could try to add a
> clean copy of the file _in_ _addition_ to an unclean one. One might end up
> with several unclean copies of a file in the archive and, if one is lucky, a
> clean one also. This will make the archive larger, but in many cases this is
> acceptable.
>
> I use dar to backup my system automatically in the background every 3 hours.
> The archive is compressed and pushed over the network to a machine with
> several hundreds of gigabytes of space. It really does not matter if the
> archive grows by a few megabytes or even more.
>
> It should, of course, be user-configurable, whether retries should take place
> and how many of them at most per file. Maybe one could also allow the user to
> make the number of retries dependent on the size of the file. So, for
> example, the user could say that for files above a certain size, no retries
> should be made. One could also allow the user to limit the total size that is
> spent on retries. There are a lot of possibilities. For my purposes, it would
> be enough if I could say: 'give every file at most n retries and do not retry
> on files larger than x bytes.'
>
>
>
> > > 2. If dar fails to integrate a file cleanly into the archive (maybe even
> > > though dar tried several times to do so, but the file keeps changing
> > > rapidly), this file could be marked as 'unclean' (or such) in the archive. On
> > > extraction, the user could decide whether such files should be extracted or
> > > not.
> >
> > This second point instead is possible to implement and is interesting.
> > This let the user keep trace of probably not well saved files. For
> > backward compatibility, the 'unclean' marking can be systematic at
> > archive creation time, but 'unclean' file should be be filtered out
> > unless the user say so using a given option. Or maybe better the
> > 'unclean' files could be filtered out by default (during file
> > extraction) but a warning/aknowledgment would be issued first before
> > starting file extraction if such file has to be filtered out.
>
> I suggest implementing two switches, say A and B (you will know better what
> letters to use). If none of them is given, the user will be prompted when the
> extraction process encounters an unclean file. If A is given, all unclean
> files are skipped automatically (maybe a warning is displayed). If B is
> given, all files (also the unclean ones, without prompting) are extracted
> (maybe with a warning). If -Q is given, I suggest that dar should behave as
> if switch A was given.
>
>
>
>
> All the best, Lasse
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Dar-discussions mailing list
> Dar-discussions-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/dar-discussions
>
>
>


-- 
Andre Ruiz  <[email protected]>
Curitiba, PR, Brasil

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV