Re: [rdiff-backup-users] More Windows/Cygwin-woes

[Ben Escoto]

>>>>> "PET" == paul-erik torronen <iso-8859-1>
>>>>> wrote the following on Thu, 31 Oct 2002 15:34:22 +0200

  PET> Having tested the same remote client from another Windows
  PET> server with the same result, I saw that there was a new version
  PET> of the cygwin with the gcc-3.2. I installed it and recompiled
  PET> succesfully the librsync-0.9.5.1 (which had failed previously
  PET> when cygwin still used gcc 2.96). Recompiled also the
  PET> rdiff-backup and made a testrun, alas with similar result.
    ...
  PET> Getting signature of
  PET> 
/cygdrive/e/test/host.domain.net/usr/share/sendmail-cf/ostype/amdahl-uts.m4

  PET> Nothing special is written on the client-side logs and no
  PET> OS-changes has been done. Also the memory-usage on the server
  PET> stays now within control. I'm a bit stumped with this since
  PET> even a client with _no_ changed data (it was shut down shortly
  PET> after a succesful backup) now shows this behaviour.

rdiff-backup apparently thought that the
/cygdrive/e/test/host.domain.net/usr/share/sendmail-cf/ostype/amdahl-uts.m4
file changed, because it tried to take a signature of it.  Since that
is when things hung it seems that maybe librsync disagrees with the
new gcc.  A quick way to test would be:

rdiff signature
/cygdrive/e/test/host.domain.net/usr/share/sendmail-cf/ostype/amdahl-uts.m4

and if that hangs, then it is a librsync problem.  If that works, but
something like:

md temp
dd if=/dev/urandom of=temp bs=1k count=32 # make 32k random file
rdiff-backup temp out
cat /dev/null > temp/foo
rdiff-backup temp out

hangs on the second rdiff-backup command, then the problem is probably
in rdiff-backup's interface _librsync code.


-- 
Ben Escoto

pgpHUX5Lx1rTz.pgp
Description: PGP signature