Re: code 11: files changed during backup

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFF9sHT1gObwed86AkRAiT7AJ0WdocDbpyHob/IMbt7EJwl1X4kOACffkoa
qVIqBbl+1GQ0tEuA78M+v3Y=
=qTTZ
-----END PGP SIGNATURE-----