[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference smurf::buildhelp

Title:USG buildhelp questions/answers
Moderator:SMURF::FILTER
Created:Mon Apr 26 1993
Last Modified:Mon Jan 20 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2763
Total number of notes:5802

1347.0. "problem with mklinks and ptos.nightly" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Sun Mar 19 1995 11:34

Date Of Receipt: 	19-MAR-1995 10:35:49.46
From: 	SMURF::QUARRY::mjr "Michael Rickabaugh USG  19-Mar-1995 1034"
To: 	odehelp@DEC:.zko.quarry
CC: 	mwarren@DEC:.zko.quarry, metsky@DEC:.zko.quarry, sue@DEC:.zko.quarry
Subj: 	problem with mklinks and ptos.nightly

When I create a new sandbox backed to ptos.nightly, and
then do a mklinks to create a link for every file, I get
this:

% mklinks .

Linking directory subtree:
  From: /usr/staff/mjr/sand/test_mklinks2/link/src/.
  To:   /advfs0/mjr/sand/test_mklinks2/src/.

./.srctemp009382: Permission denied
./.srctemp009397: Permission denied
./.srctemp009412: Permission denied
./.srctemp009427: Permission denied
%

I do not have this problem when backing to goldminos.bl6, ptliteos.nightly,
or ptos.

I do not _want_ this problem with ptos.nightly.

Why does this occur?

-mike

T.RTitleUserPersonal
Name
DateLines
1347.1Re: problem with mklinks and ptos.nightlyAOSG::FILTERAutomatic Posting Software - mail to flume::puckSun Mar 19 1995 23:3714
Date Of Receipt: 	19-MAR-1995 23:03:10.45
From: 	SMURF::FLUME::jmcg "Jim McGinness"
To: 	[email protected]
CC: 	odehelp@DEC:.zko.flume
Subj: 	Re:  problem with mklinks and ptos.nightly

Is this a new problem?  It looks like it should have been happening since
14 Sep 1994.  That's the date on these (empty) directories in the ptos
submit pool.  Of course, the permissions are _supposed_ to be 755 instead
of 700, so it looks like rdist is screwing up.  You can safely ignore the
messages until Josh & co. can clean up whatever is causing the problem.

 -- jmcg

1347.2Re: problem with mklinks and ptos.nightlyAOSG::FILTERAutomatic Posting Software - mail to flume::puckMon Mar 20 1995 09:4013
Date Of Receipt: 	20-MAR-1995 09:07:19.66
From: 	SMURF::QUARRY::mjr "Michael Rickabaugh USG  20-Mar-1995 0904"
To: 	Jim McGinness <jmcg@DEC:.zko.quarry>
CC: 	odehelp@DEC:.zko.quarry
Subj: 	Re: problem with mklinks and ptos.nightly

>Is this a new problem?

I haven't done a mklinks on the entire tree for a long
time--this is certainly the first time I did to ptos.nightly.

-mike

1347.3Re: problem with mklinks and ptos.nightlyAOSG::FILTERAutomatic Posting Software - mail to flume::puckMon Mar 20 1995 10:4340
Date Of Receipt: 	20-MAR-1995 10:02:26.56
From: 	SMURF::QUARRY::"[email protected]" "20-Mar-1995 0959"
To: 	[email protected]
CC: 	[email protected], [email protected],
	[email protected], [email protected]
Subj: 	Re: problem with mklinks and ptos.nightly

srctmp??? is an artifact of the submit tree and is just unnecessary baggage in 
this tree. We clean them out periodically - just ignore this.


	-Grant
| 
| When I create a new sandbox backed to ptos.nightly, and
| then do a mklinks to create a link for every file, I get
| this:
| 
| % mklinks .
| 
| Linking directory subtree:
|   From: /usr/staff/mjr/sand/test_mklinks2/link/src/.
|   To:   /advfs0/mjr/sand/test_mklinks2/src/.
| 
| ./.srctemp009382: Permission denied
| ./.srctemp009397: Permission denied
| ./.srctemp009412: Permission denied
| ./.srctemp009427: Permission denied
| %
| 
| I do not have this problem when backing to goldminos.bl6, ptliteos.nightly,
| or ptos.
| 
| I do not _want_ this problem with ptos.nightly.
| 
| Why does this occur?
| 
| -mike
| 


1347.4Re: problem with mklinks and ptos.nightlyAOSG::FILTERAutomatic Posting Software - mail to flume::puckMon Mar 20 1995 13:5313
Date Of Receipt: 	20-MAR-1995 13:34:18.47
From: 	SMURF::FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE"
To: 	jmcg@DEC:.zko.flume, [email protected]
CC: 	odehelp@DEC:.zko.flume
Subj: 	Re:  problem with mklinks and ptos.nightly

Actually, Jim, we'd really like the modes to be 750 eventually so as not
to allow every guest to be able to access sources, but that's another story...

-josh

I'll look into the problem...