[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

1705.0. "sandbox locking problem" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Wed Aug 16 1995 19:02

Date Of Receipt: 	16-AUG-1995 13:37:02.33
From: 	SMURF::ALPHA::"rll@unx.dec.com" "16-Aug-1995 1335"
To: 	odehelp@zk3.dec.com
CC: 	
Subj: 	sandbox locking problem

Someone <cntrl> C'd a bco of a file in a sandbox. When he tries to
bco that file again he gets:

	Waiting for sandbox lock (with lockf())

Does this mean his workstation is not using NFS locking?

Thanks,

Rich
================================================================
Rich Larsen, M/S: UNX			TCP/IP: rll@unx.dec.com
USSG/User Env. & Std. Group		DECnet: UNXA::LARSEN
Digital Equipment Corporation		FAX:	908-577-6003
200 Route 9 North			Voice:	908-577-6083	
Manalapan, New Jersey 07726		DTN:	462

T.R Title User Personal
Name Date Lines

1705.1 Re: sandbox locking problem AOSG::FILTER Automatic Posting Software - mail to flume::puck Wed Aug 16 1995 20:06 38

T.R	Title	User	Personal Name	Date	Lines
1705.1	Re: sandbox locking problem	AOSG::FILTER	Automatic Posting Software - mail to flume::puck	`Wed Aug 16 1995 20:06`	38
	Date Of Receipt: 16-AUG-1995 14:56:57.70 From: SMURF::FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE 16-Aug-1995 1453" To: Rich Larsen <rll@unx.dec.com> CC: odehelp@zk3.dec.com Subj: Re: sandbox locking problem Rich, This just means that the lock on <sandbox>/src/.BCSlock still exists from the ^C'd operation. All that's needed is to rm this file, and the next b* operation will re-create it. Locks on this file keep multiple b* operations going on in different windows for the same sandbox in sync. It always worked this way, but now with locking it's more robust. -josh > > Someone <cntrl> C'd a bco of a file in a sandbox. When he tries to > bco that file again he gets: > > Waiting for sandbox lock (with lockf()) > > Does this mean his workstation is not using NFS locking? > > Thanks, > > Rich > ================================================================ > Rich Larsen, M/S: UNX TCP/IP: rll@unx.dec.com > USSG/User Env. & Std. Group DECnet: UNXA::LARSEN > Digital Equipment Corporation FAX: 908-577-6003 > 200 Route 9 North Voice: 908-577-6083 > Manalapan, New Jersey 07726 DTN: 462

Date Of Receipt: 	16-AUG-1995 14:56:57.70
From: 	SMURF::FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE  16-Aug-1995 1453"
To: 	Rich Larsen <rll@unx.dec.com>
CC: 	odehelp@zk3.dec.com
Subj: 	Re: sandbox locking problem

Rich,

This just means that the lock on <sandbox>/src/.BCSlock still 
exists from the ^C'd operation.  All that's needed is to rm this
file, and the next b* operation will re-create it.

Locks on this file keep multiple b* operations going on in 
different windows for the same sandbox in sync.  It always worked
this way, but now with locking it's more robust.

-josh

> 
> Someone <cntrl> C'd a bco of a file in a sandbox. When he tries to
> bco that file again he gets:
> 
> 	Waiting for sandbox lock (with lockf())
> 
> Does this mean his workstation is not using NFS locking?
> 
> Thanks,
> 
> Rich
> ================================================================
> Rich Larsen, M/S: UNX			TCP/IP: rll@unx.dec.com
> USSG/User Env. & Std. Group		DECnet: UNXA::LARSEN
> Digital Equipment Corporation		FAX:	908-577-6003
> 200 Route 9 North			Voice:	908-577-6083	
> Manalapan, New Jersey 07726		DTN:	462