[3639] in Release_7.7_team
[Fwd: Re: problems with local-lockers]
daemon@ATHENA.MIT.EDU (Bill Cattey)
Thu Dec 19 17:55:39 2002
From: Bill Cattey <wdc@MIT.EDU>
To: tbelton@mit.edu, rbasch@mit.edu
Cc: release-team@mit.edu
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 19 Dec 2002 17:55:35 -0500
Message-Id: <1040338535.17734.24.camel@tokata.mit.edu>
Mime-Version: 1.0
Alex's comment on acroread below causes me to ask:
Does this end up advocating for acroread ALSO going into the release
if Mozilla does?
-wdc
-----Forwarded Message-----
From: Alex T Prengel <alexp@MIT.EDU>
To: Greg Hudson <ghudson@MIT.EDU>
Cc: alexp@MIT.EDU, jweiss@MIT.EDU, testers@MIT.EDU
Subject: Re: problems with local-lockers
Date: 19 Dec 2002 12:14:51 -0500
>On Thu, 2002-12-19 at 05:30, Jonathon Weiss wrote:
>>
>> I ran into a couple of problems with the local-lockers functionality.
>>
>> 1) The directory /var/athena/local/acro_v5.0.5/ is mode 666,
>> presumably because the top level of the volume in afs is.
>
>Good catch. I think this is best fixed for now by Alex doing a chmod
>go-w of the top level of the volume
Done (in the R/W volume). Should be visible by next AFS propagation.
Jonathon also reports a second issue:
>2) acroread is still run out of afs, apparently because
> /mit/acro_v5.0.5/distrib/$ATHENA_SYS/bin/acroread is a script that
> calls it with a full afs path.
This could be a real hassle- acroread is intricately bound to Netscape/Mozilla
configuration settings that rely on these paths, and things would almost
surely break and take a lot of work on my and Todd's part to fix if we changed
this. I really don't want to mess around with this unless it's absolutely
essential.
Alex
