--- cppjavaperl <[EMAIL PROTECTED]> wrote:
> I have a server running BackupPC 2.1.0pl1. I was having problems
> with
> a particular Windows XP client. This client had been backing up fine
> in the past. I had some problems with the Cygwin installation on it,
> so I re-installed Cygwin (moving the old version out of the way, so
> I would be sure to get a clean install).
>
> Since re-installing cygwin, and removing and reinstalling the rsync
> daemon, I had not been able to get a backup to complete. The process
> would stop backing up any files after a few hours, but it did not
> exit, and the backup was never completed. It would just show up in
> "Currently Running Jobs" until I killed it. I had my ClientTimeout
> set to 72000 and I'm sure I always killed it before that much time
> had
> passed. :-)
>
> I am using the latest version of rsync (from the BackupPC download
> area on SourceForge). I decided to run a manual rsync on my
> BackupPC server and see what happened. I was under the impression at
> the time that the problem was with something in my
> C:\Windows\system32
> folder, so I tried to run rsync and just sync that folder. I was
> surprised to find that running the following command failed:
>
> rsync -avvvv [EMAIL PROTECTED]::C/windows/system32 .
>
> Here is the error I got:
>
> rsync: pop_dir "/cygdrive/c/WINDOWS/system32/c:" (in C) failed: No
> such file or directory (2)
>
> I found some information on this problem in this thread on
> devshed.com:
>
>
http://archives.devshed.com/forums/networking-100/no-such-file-or-directory-but-hey-the-files-are-there-2113763.html
>
> (Quoting Matt McCutchen):
>
> I see what is going on here. In order to scan under a source
> argument for files to add to the file list, the sender needs to
> be in the directory that maps to the root of the transfer. In
> the
> first command, the root of the transfer is the module, and the
> sender is already there. But in the second, the root of the
> transfer is the "backup" subdirectory, so the sender needs to
> push_dir into "backup", scan, and pop_dir back to the module.
>
> As the sender is starting up, it pushes into "u:" by calling
> chdir("u:"). Cygwin understands "u:" as an absolute path for the
> U drive, so this works fine. But the sender assumes "u:" is
> relative because it doesn't begin with a slash, so the sender
> thinks it has entered "/cygdrive/c/WINDWS/system32/u:". When
> the
> sender tries to pop back into this directory later, the error
> occurs.
>
> I was kind of surpised at this, since I have several Windows boxes
> running an rsync daemon, and I have always configured the module for
> the C: drive with a path of "C:" (which is the example given in the
> BackupPC rsync package on SourceForge). So, I changed the path to
> /cygdrive/c, restarted rsyncd, and retested the manual
> rsync -avvvv ... command I had tried earlier. This worked fine, so I
> decide to run "BackupPC_dump -v -i mymachine" manually so I could see
> what was happening with the backup.
>
> Things went along swimmingly for a few hours, and then suddenly
> BackupPC_dump segfaulted! No error messages, no nothing, just
> SEGMENTATION FAULT.
>
> I searched the mailing list, but couldn't seem to find a match for
> the
> problem. The only post that seemed to match was one where Craig had
> said you could get a segfault if the client sent two files of the
> exact same path and name. I didn't see how that could be the case so
> I kept looking.
>
> By looking through the Xferlog and directories of the prematurely
> aborted backup, I found that the backup was aborting in the directory
> which contained my original Cygwin install (I had renamed the
> directory to move it out of the way, so that I could grab files
> from it later).
>
> I had made multiple attempts to recover my backed up cygwin
> configuration. Presently I don't have broadband available, so it
> wasn't as simple as re-downloading all of the Cygwin packages I
> wanted. I had a repository of packages grabbed mostly from the same
> mirror, but there were a few packages from other mirrors, along with
> some I had previously burned to CD from work.
>
> I think the real problem, however, stemmed from me trying to restore
> my Cygwin directory from my backuppc server. I *did* have problems
> installing Cygwin again, if I picked anything other than a "Default"
> install. So, after getting a successful (no errors) base install of
> Cygwin, I tried to restore from a BackupPC-generated tar file (over
> the top of a freshly-installed) Cygwin. That hadn't worked, and
> so I gave up, moved this test cygwin install directory out of the
> way,
> re-installed Cygwin with the "Default" install and moved on.
>
> This post is already far too long, so I'll get to the point.
>
> Craig was right. :-)
>
> The problem was that I had programs in my c:/cygwin directory that
> existed as *both* regular empty files and as Windows shortcuts (.lnk
> files). The first I found was /bin/aclocal, then /bin/autoconf,
> /bin/automake. For each of these files there was a zero byte
> file with the name you were expecting (like /bin/autoconf --
> no extension). *But* there was also a
> c:/cygwin/bin/autoconf.lnk which pointed to another file.
> Problem was, under rsync, these were both transmitted with the
> filename /cygdrive/c/cygwin/bin/autoconf. That was causing
> the segfault.
>
> I changed my rsyncd.conf file to point to the old cygwin/bin
> directory
> which had the "duplicate" files in it, restarted rsyncd, and re-ran
> my
> BackupPC_dump command. *BINGO* -- almost immediately it segfaulted
> on
> the first of those files it found.
>
> To fix this problem, I wrote a small perl program to search
> directories for files which occurred both with and without a .lnk
> extension. The search directories were given as command line
> arguments to the program.
>
> I ran this program under ActiveState perl, because cygwin's perl
> would
> interpret the filenames and not give me what I wanted. Here is the
> program:
>
>
> use File::Find;
>
> find(\&checkForLnkFile, @ARGV);
>
> sub checkForLnkFile
> {
> return if ( -d $_ );
>
> return if (lc(substr($_, -4)) eq '.lnk');
>
> print $File::Find::dir."/$_\n" if ( -f $_.'.lnk' );
> }
>
>
> This program printed me out a list of the offending files (without
> the
> .lnk) extension. To test, I removed all of the .lnk files from
> the directory I had last run BackupPC_dump against, and reran
> BackupPC_dump. *BINGO* again! This time the backup completed with
> no
> problems.
>
> So, I removed the rest of the duplicate files, reset the rsyncd.conf
> to backup the whole drive again, and am presently running
> BackupPC_dump again (which I fully expect to complete without a
> hitch).
>
> After spending all this time figuring this out, I decided to share it
> here in case someone else is having the problem. Also, I was
> wondering if perhaps it would be a good idea to guard against this
> problem with some kind of error from BackupPC. I know my server is
> running an older version, so perhaps this has been addressed in one
> of
> the 3.x versions. But I didn't find anything about it on the mailing
> list (other than Craig's comment that led me to the solution), so I
> suspect that even the 3.x versions are susceptable to this.
>
> Hope this helps someone out,
>
> cppjavaperl
>
>
>
>
>
>
>
>
>
>
Replying to my own post here. The backup turned out to be a "leet"
backup :-) It took 1337 minutes, due to the other backup running at
the same time earlier in the day. However, it did complete. Lest
anyone should think that I had just not waited long enough before, it
is important to note that when the backup was "hung" before, it was
obvious that the client was no longer sending any files to the server
(there was basically no disk activity at all on the client).
cppjavaperl
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
