When a document is opened for read/write by OpenOffice 2.0 on Solaris
8, that document file gets write locked, so that no one else can update
it. (Which is a good thing.)

What sometimes happens though is that a document is opened (and
therefore locked) by a mysterious someone, and the rest of us on this
fairly good-sized project can't figure out who has the document open in
order to get them to release it.

Open or closed, the file's permissions are 664, and so we're trying to
find out who's got the lock on the file. I've been all over the web and
newsgroups, but haven't come up with anything yet.

Any suggestions would be appreciated--thanks.

Marc A. Criley
Cohesion Force, Inc.

In article <1165331144.851036.38820@73g2000cwn.googlegroups.com>,
 "mcriley" <marc.a.criley@lmco.com> wrote:

> When a document is opened for read/write by OpenOffice 2.0 on Solaris
> 8, that document file gets write locked, so that no one else can update
> it. (Which is a good thing.)
> 
> What sometimes happens though is that a document is opened (and
> therefore locked) by a mysterious someone, and the rest of us on this
> fairly good-sized project can't figure out who has the document open in
> order to get them to release it.
> 
> Open or closed, the file's permissions are 664, and so we're trying to
> find out who's got the lock on the file. I've been all over the web and
> newsgroups, but haven't come up with anything yet.
> 
> Any suggestions would be appreciated--thanks.
> 
> Marc A. Criley
> Cohesion Force, Inc.

It must be a running process.  Have you tried lsof (not installed by 
vanilla Solaris)?

Or if you don't have access to lsof (requires root), locking is a 
function of the application rather than the OS.  Your best bet might be 
to download OpenOffice and puruse the source code.  Maybe it can show 
what, if any, tracks this.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...

mcriley <marc.a.criley@lmco.com> wrote:
> What sometimes happens though is that a document is opened (and
> therefore locked) by a mysterious someone, and the rest of us on this
> fairly good-sized project can't figure out who has the document open in
> order to get them to release it.

Depends on exactly the locking mechanism used.

If it's using OS locking, run 'fuser' on the file.  It'll show the PID
of any processes that have the file open and/or locked.  Hopefully you
can then track down the owner of that PID.

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

mcriley wrote:

> When a document is opened for read/write by OpenOffice 2.0 on Solaris
> 8, that document file gets write locked, so that no one else can update
> it. (Which is a good thing.)
> 
> What sometimes happens though is that a document is opened (and
> therefore locked) by a mysterious someone, and the rest of us on this
> fairly good-sized project can't figure out who has the document open in
> order to get them to release it.
> 
> Open or closed, the file's permissions are 664, and so we're trying to
> find out who's got the lock on the file. I've been all over the web and
> newsgroups, but haven't come up with anything yet.
> 
> Any suggestions would be appreciated--thanks.
> 
> Marc A. Criley
> Cohesion Force, Inc.
> 

man fuser

Richard B. Gilbert wrote:

> man fuser

fuser doesn't work for this because we've got over a hundred
workstations on the project and the file resides on a shared volume.

I'm hesitant to try to get any new software (such as lsof) on the
system because there's such a significant bureaucratic chain to go
through.

Marc

mcriley wrote:

> Richard B. Gilbert wrote:
> 
> 
>>man fuser
> 
> 
> fuser doesn't work for this because we've got over a hundred
> workstations on the project and the file resides on a shared volume.
> 
> I'm hesitant to try to get any new software (such as lsof) on the
> system because there's such a significant bureaucratic chain to go
> through.
> 
> Marc
> 

If you give access to the file to over one hundred users, such problems 
seem a natural consequence!  It would seem that you have no choice but 
to obtain and install a tool such as lsof.  And when you find the 
asshole who has the file locked, perhaps you can have him killed!

In article <M5ydnUj7ZYNfJOjYnZ2dnUVZ_oGdnZ2d@comcast.com>,
 "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:

> mcriley wrote:
> 
> > Richard B. Gilbert wrote:
> > 
> > 
> >>man fuser
> > 
> > 
> > fuser doesn't work for this because we've got over a hundred
> > workstations on the project and the file resides on a shared volume.
> > 
> > I'm hesitant to try to get any new software (such as lsof) on the
> > system because there's such a significant bureaucratic chain to go
> > through.
> > 
> > Marc
> > 
> 
> If you give access to the file to over one hundred users, such problems 
> seem a natural consequence!  It would seem that you have no choice but 
> to obtain and install a tool such as lsof.  And when you find the 
> asshole who has the file locked, perhaps you can have him killed!

And install a code management system while you're at it.  This senario 
just screams CVS (or whatever).  What's the lost to productivity this 
has caused so far?  

Is it worth (a) installing tools to solve the problem or (b) standing 
behind a bureaucratic chain and saying "it's production" with how many 
people sitting on their hands because they can't do their work because 
of one twit?

If the answer is (b), you've got bigger problems.  Lots of organizations 
get into this pickle.  There are lots of solutions to it as well.  
You'll have to find the one that works for you.  Hint: if it involves 
firearms, that can be career limiting.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...

mcriley <marc.a.criley@lmco.com> wrote:

> Richard B. Gilbert wrote:

>> man fuser

> fuser doesn't work for this because we've got over a hundred
> workstations on the project and the file resides on a shared volume.

Ah, I didn't understand that this was shared out via NFS.

> I'm hesitant to try to get any new software (such as lsof) on the
> system because there's such a significant bureaucratic chain to go
> through.

I don't believe lsof will help anyway.  Just like fuser, you'd have to
run it on the individual workstation.  Even if it could tell you
anything, all it would be able to say is that lockd had a lock on it.

It would be nice if you could query the NFS lock daemon to dump status,
but I don't know any way to do so. 

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

Michael Vilain  wrote:

> And install a code management system while you're at it.  This senario 
> just screams CVS (or whatever).

Hum, for a binary file like an openoffice file, cvs is just an other
locking mechanism, and not a very good one. I believe office has some
features to merge modifications done by several users (at least microsoft
communicated on the fact that its version had domething like that), you
might want to look into that.

ls -l

Barry
=====
Home page
http://members.iinet.net.au/~barry.og

In article <e4gkn25h2v2glb6c4uiokf1msesl525bon@4ax.com>,
 Barry OGrady <god_free_jones@yahoo.com> wrote:

> ls -l
> 
> Barry
> =====
> Home page
> http://members.iinet.net.au/~barry.og

I'm just hypothesizing here.  If NFS mounted copy of OpenOffice is being 
used to access a NFS document that has wide access and reports that the 
document is "locked", something is tracking that.  If the file doesn't 
have a lock status (shown by ls -l) then it's internal to OpenOffice and 
good luck wandering around the source trying to figure that out.  Even 
in a distributed environment as you mentioned, I don't see a way to 
figure this out other than to get a ClueByFour(tm) from the lumbar yard 
and apply it librally about the neck and shoulders of the culprit.

Then FIX THIS PROCESS.  IT TOTALLY BROKEN.  You mentioned you can't 
install "extra tools" like lsof (which is free) or a binary-compatible 
CVS (e.g. IBM's Documentum--not free and requires a fullsized server but 
allows tracking for engineering documents, PDFs, Word, anything really).
  
If you're just a worker drone complaining about the problem, thanks for 
sharing.  If you want to propose a solution that will save your company 
time, money, and productivity.  The current cooperative solution isn't 
working.  So fix it.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...