Holger writes:
> Another possibility could be to write a wrapper around either ssh on the
> server or tar on the client to change an exit code of 1 to an exit code of 0,
> but that probably has the problem of affecting more serious errors as well
> (if it was as simple as patching exit code 1 to 0, I guess there would be a
> fix in place already). You could even do this in BackupPC itself, *possibly*
> as simple as changing line 213 (in 3.0.0beta3) in Xfer::Tar.pm as in
>
> - if ( !close($t->{pipeTar}) ) {
> + if ( !close($t->{pipeTar}) and $? != 256 ) {
>
> but that
> a) is *totally* untested,
> b) will affect all clients and not only one and
> c) will make all failures returning exit code 1 to be regarded as "ok"
> (provided it even works)
>
> - four good reasons not to try it unless you are really desperate :-). With
> a wrapper around ssh or tar you can at least limit the effect to one client.
> But downgrading tar still seems safest to me.
>
> I hope someone can give you a better solution.
Your solution is fine. I looked at the source for tar 1.16 and it
returns an exit status of 1 only in the case when a file changed
during reading. More specifically:
- the file length changed during reading (eg: more/less bytes
read than the file size returned by stat), or
- the mtime changed while the file was being archived.
> d) will of course void your BackupPC warranty ;-)
You are right of course :)
I'll make the change in 2.x and 3.x.
Craig
-------------------------------------------------------------------------
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
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
