Re: Re[2]: [rdiff-backup-users] rdiff-backup completes without errors, but then have a corrupt archive...

[Andrew Ferguson]

On Mar 30, 2009, at 9:29 PM, address@hidden wrote:
> Yeah, it is, and I was pondering doing so.
>
> Are the exit codes the same, and available to cygwin event though
> it's a windows binary? (I do see the output is the same unix style
> output (with a unix vs dos line return).

The exit codes should be the same, but, truthfully, the state of rdiff- 
backup's exit codes are not very good. I don't think they're  
documented anywhere (someone correct me if I'm wrong). There's even a  
bug open in Ubuntu #128244 which basically amounts to "rdiff-backup  
has unhelpful error codes".

That said, I would be more than happy to implement useful error codes.  
I just don't know what would be useful to system administrators. :-)

In that bug, https://bugs.launchpad.net/ubuntu/+source/rdiff-backup/+bug/128244 
 , I proposed:
0 = no error occurred
1 = unrecoverrable error
2 = another rdiff-backup instance running
3 = recoverrable error (link down, interrupted, etc.)

but no one responded whether those would be good or not, so nothing  
became of it...

> What if I have a remote source/destination and I need to do SSH over  
> it? (Isn't
> putty quite messy to setup vs cygwin?)

I guess it's a matter of opinion. To me, it seems like Cygwin is much  
more invasive than just dropping in a few binaries for putty....

> Other than remote destinations, I think the windows binary will work.
>
> As for 1.3.3, how "unstable" is it? Do I dare roll it out in a
> production environment?


For rdiff-backup, "unstable" has meant that the developers are free to  
break the network protocol and adjust the internal repository format.  
If you are using the development version, the expectation is that you  
are willing to keep both sides of the repository in sync (version- 
wise), read the mailing list traffic, and assist as best as possible  
with any debugging efforts.

1.3.3 is basically 1.2.8 with some extra features, such as --min-file- 
size and --max-file-size agreeing with the man page, the --use- 
compatible-timestamps option, taking the start and end times from the  
same system, improvements to how rdiff-backup handles files which it  
cannot read, and escaping trailing spaces and periods as necessary.

Josh Nisly has recently developed a Unicode patch for 1.3.x which we  
hope to incorporate soon. That will allow the native Windows port to  
finally support paths with more than ~250 characters.


Andrew