| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 117.1 | re: Why can t I access agosmaint.bl1? | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Mon Jun 07 1993 18:28 | 65 |
| Date Of Receipt: 7-JUN-1993 10:33:54.38
From: WASTED::jmf "Joshua M. Friedman ULTRIX SDE 07-Jun-1993 1034"
To: tpb@wasted:zko.dec
CC: odehelp@wasted:zko.dec
Subj: re: Why can't I access agosmaint.bl1?
Tom, in fact the bug is that the agosmaint.bl1 entry was not removed
from the ode_fstab when the agosmaint.bl1 tree itself was deleted (we
save online the last 3 trees (full or pre baselevels) for each stream.
agosmaint.bl1 has long since been retired. The ode_fstab entry is there
because the alpha.dsk5 disk which stores alpha.bl012 was "backing" the
agosmaint.bl1 tree. The link that exists in /usr/sde/osf1/build is in
fact wrong, but in fact should not exist at all -- I'll remove it now.
It is there as an artifact of how we re-created all the links in
that directory after the /share diskname reshuffle. If the entry had
been removed from the ode_fstab as it should have been, this link would
not exist now.
Sorry for the confusion. If you *REALLY* need to access the agosmaint.bl1
backingtree, the release engineering group has it archived. Contact
Barry Sullivan (barrys) for this...
Thanks for catching this for us... -josh
------- Forwarded Message
Return-Path: [email protected]
Received: by flume.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA07776; Mon, 7 Jun 1993 10:25:10 -0400
Message-Id: <[email protected]>
To: [email protected]
Subject: Why can't I access agosmaint.bl1?
Date: Mon, 07 Jun 93 10:25:09 -0400
From: "Dr. Tom Blinn (DTN 381-0646, ZKO3 3X05)" <[email protected]>
X-Mts: smtp
I need to access the agosmaint.bl1 backing tree.
When I odemount it, I don't get any errors.
However, when I try to follow the symbolic link from
/usr/sde/alpha/build/agosmaint.bl1
to
/share/bigbld/build/alpha.dsk5/agosmaint.bl1
I get a "not found" error.
All the other agosmaint disks exported by bigbld have
names like agos.dsk*; this is the only disk exported
into /share/bigbld/build that seems to have the name
alpha.bl*.
I suspect there's an error in the ode_fstab database
that mis-labels the disk. Alternatively, the disk is
listed with the correct name but the directories are
not there. Either way, I can't get to the files.
Help!
Tom
------- End of Forwarded Message
|
| 117.2 | Re: Why can t I access agosmaint.bl1? | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Mon Jun 07 1993 18:30 | 40 |
| Date Of Receipt: 7-JUN-1993 10:51:06.45
From: FLUME::tpb "Thomas Prescott Blinn USG"
To: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <flume::jmf>
CC: flume::odehelp
Subj: Re: Why can't I access agosmaint.bl1?
Thanks for the prompt reply. I can live without it. Since it seemed to
still be accessible, I would have used it, since it's what backs up the
agosminor.bl1 pool, and I wanted to determine what files changed between
the two pools (which I can relatively easily do with standard utilities
if I can get to the two pools).
What is the impact on agosminor.bl1 (which meets the "save online" test)
when the pool that it's backed by (agosmaint.bl1 in this case) is taken
off-line? Does that mean that attempts to build in agosminor.bl1 fail?
Maybe we need to think about the impact of having pools backed by pools
(backed by pools?) has on the "when to retire a pool" policy.
Tom
> Tom, in fact the bug is that the agosmaint.bl1 entry was not removed
> from the ode_fstab when the agosmaint.bl1 tree itself was deleted (we
> save online the last 3 trees (full or pre baselevels) for each stream.
>
> agosmaint.bl1 has long since been retired. The ode_fstab entry is there
> because the alpha.dsk5 disk which stores alpha.bl012 was "backing" the
> agosmaint.bl1 tree. The link that exists in /usr/sde/osf1/build is in
> fact wrong, but in fact should not exist at all -- I'll remove it now.
> It is there as an artifact of how we re-created all the links in
> that directory after the /share diskname reshuffle. If the entry had
> been removed from the ode_fstab as it should have been, this link would
> not exist now.
>
> Sorry for the confusion. If you *REALLY* need to access the agosmaint.bl1
> backingtree, the release engineering group has it archived. Contact
> Barry Sullivan (barrys) for this...
>
> Thanks for catching this for us... -josh
|
| 117.3 | Re: Why can t I access agosmaint.bl1? | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Mon Jun 07 1993 18:31 | 53 |
| Date Of Receipt: 7-JUN-1993 11:01:33.29
From: FLUME::"[email protected]" "Grant Van Dyck"
To: "Dr. Tom Blinn (DTN 381-0646, ZKO3 3X05)" <[email protected]>
CC: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <[email protected]>,
[email protected]
Subj: Re: Why can't I access agosmaint.bl1?
The only connection this tree should have to agosmaint.bl1 is the symlink
"link" which is primarily an artifact of the tree's creation. Baselevel trees
are standalone trees and should have NO dependencies at all on any other
trees. The ONLY trees that should be shared sandboxes (backed by other trees)
are the submit trees.
Since this tree was created we have taken some steps to ensure that that
is true.
-Grant
| Thanks for the prompt reply. I can live without it. Since it seemed to
| still be accessible, I would have used it, since it's what backs up the
| agosminor.bl1 pool, and I wanted to determine what files changed between
| the two pools (which I can relatively easily do with standard utilities
| if I can get to the two pools).
|
| What is the impact on agosminor.bl1 (which meets the "save online" test)
| when the pool that it's backed by (agosmaint.bl1 in this case) is taken
| off-line? Does that mean that attempts to build in agosminor.bl1 fail?
|
| Maybe we need to think about the impact of having pools backed by pools
| (backed by pools?) has on the "when to retire a pool" policy.
|
| Tom
|
| > Tom, in fact the bug is that the agosmaint.bl1 entry was not removed
| > from the ode_fstab when the agosmaint.bl1 tree itself was deleted (we
| > save online the last 3 trees (full or pre baselevels) for each stream.
| >
| > agosmaint.bl1 has long since been retired. The ode_fstab entry is there
| > because the alpha.dsk5 disk which stores alpha.bl012 was "backing" the
| > agosmaint.bl1 tree. The link that exists in /usr/sde/osf1/build is in
| > fact wrong, but in fact should not exist at all -- I'll remove it now.
| > It is there as an artifact of how we re-created all the links in
| > that directory after the /share diskname reshuffle. If the entry had
| > been removed from the ode_fstab as it should have been, this link would
| > not exist now.
| >
| > Sorry for the confusion. If you *REALLY* need to access the agosmaint.bl1
| > backingtree, the release engineering group has it archived. Contact
| > Barry Sullivan (barrys) for this...
| >
| > Thanks for catching this for us... -josh
|
| 117.4 | Re: Why can t I access agosmaint.bl1? | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Mon Jun 07 1993 18:32 | 71 |
| Date Of Receipt: 7-JUN-1993 11:12:30.97
From: WASTED::jmf "Joshua M. Friedman ULTRIX SDE 07-Jun-1993 1113"
To: [email protected]
CC: odehelp@wasted:zko.dec
Subj: Re: Why can't I access agosmaint.bl1?
Tom, we believe we've taken the steps to make all the baselevel trees
standalone, so, while there is a "link" file that points to something
which doesn't exist, that link should never actually need to be
traversed to check out files, do builds, etc.
Please let us know if any trees are broken in this respect, however. It
initally was not the case; there were interdependencies, and we believe
all the trees are self-contained now. There are also more steps being
taken in this direction on a continuing basis to improve the way we
accomplish this with regard to rc_file nesting and build rules.
-josh
------- Forwarded Message
Return-Path: [email protected]
Received: by flume.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA08765; Mon, 7 Jun 1993 10:51:55 -0400
Message-Id: <[email protected]>
To: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <[email protected]>
Cc: [email protected]
Subject: Re: Why can't I access agosmaint.bl1?
In-Reply-To: Your message of "Mon, 07 Jun 93 10:34:42."
<[email protected]>
Date: Mon, 07 Jun 93 10:51:54 -0400
From: "Dr. Tom Blinn (DTN 381-0646, ZKO3 3X05)" <[email protected]>
X-Mts: smtp
Thanks for the prompt reply. I can live without it. Since it seemed to
still be accessible, I would have used it, since it's what backs up the
agosminor.bl1 pool, and I wanted to determine what files changed between
the two pools (which I can relatively easily do with standard utilities
if I can get to the two pools).
What is the impact on agosminor.bl1 (which meets the "save online" test)
when the pool that it's backed by (agosmaint.bl1 in this case) is taken
off-line? Does that mean that attempts to build in agosminor.bl1 fail?
Maybe we need to think about the impact of having pools backed by pools
(backed by pools?) has on the "when to retire a pool" policy.
Tom
> Tom, in fact the bug is that the agosmaint.bl1 entry was not removed
> from the ode_fstab when the agosmaint.bl1 tree itself was deleted (we
> save online the last 3 trees (full or pre baselevels) for each stream.
>
> agosmaint.bl1 has long since been retired. The ode_fstab entry is there
> because the alpha.dsk5 disk which stores alpha.bl012 was "backing" the
> agosmaint.bl1 tree. The link that exists in /usr/sde/osf1/build is in
> fact wrong, but in fact should not exist at all -- I'll remove it now.
> It is there as an artifact of how we re-created all the links in
> that directory after the /share diskname reshuffle. If the entry had
> been removed from the ode_fstab as it should have been, this link would
> not exist now.
>
> Sorry for the confusion. If you *REALLY* need to access the agosmaint.bl1
> backingtree, the release engineering group has it archived. Contact
> Barry Sullivan (barrys) for this...
>
> Thanks for catching this for us... -josh
------- End of Forwarded Message
|