[7483] in SIPB bug reports
Re: sipb.mit.edu to athena.mit.edu synctree errors
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Mon Jan 17 06:08:07 2000
Message-Id: <200001171108.GAA23588@shock-treatment.mit.edu>
To: Jacob Morzinski <jmorzins@MIT.EDU>
Cc: sipb-afsreq@MIT.EDU, bug-sipb@MIT.EDU
In-Reply-To: Your message of "Mon, 17 Jan 2000 04:52:07 EST."
<Pine.GSO.4.21.0001170446001.11986-100000@home-on-the-dome.mit.edu>
Date: Mon, 17 Jan 2000 06:08:01 -0500
From: Garry Zacheiss <zacheiss@MIT.EDU>
>> Perhaps someone can help me with a question. What's the purpose
>> of the athena-cell copy of the sipb locker?
In order to keep everything in the locker fully accessible in the
event that the sipb cell goes down for an extended period of time.
>> Granted, temporarily losing the pine source tree is not a big
>> deal. Still, is obeying .rconf files a known bug/feature?
It's a known property of synctree to parse .rconf files as it
descends the tree unless you tell it not to. I've told it not to by
adding -nosrcrules to the synctree invocation that's run nightly, and
rerun synclocker so there's now a full copy of the pine source in the
athena cell.
While I was at it, I updated /mit/sipb/.rconf to ignore OldFiles
directories, since last night's blowout was from someone mounting
/mit/sipb/src/OldFiles, which made the contrib.sipb.src -c athena try to
double it's size and fail.
Garry
