Seems to work for me.

I've tried the command

  env SAL_ENABLE_FILE_LOCKING=1 $HOME/OpenOffice.org1.0.1/soffice

on two solaris 8 boxes and then tried editing the same file in the
two OO instances.  The second OO copy could only "view" the file.
So, the locking works as expected.


The "SAL-ENABLE-FILE-LOCKING=1: not found" error is OK.  There
should really be underlines in that shell variable,  a hyphen/minus
character does *not* work.  This is standard bourne shell syntax:

% sh
$ a-b-c=1
a-b-c=1: not found
$ a_b_c=1

Oh no it doesn't, oh yes it does, oh no it doesn't...

Does issueilla sound like a pantomime to you too?

Again...
FILE LOCKING DOES NOT WORK.

One more time...
It does NOT WORK!!!!!!

Interestingly it does work for the old sdm 5.2 files, I can't think
why but then I don't know what method is being used to lock the files.

I've tried this several more times, I'm using system patched to
August-2002 standard. I'm using OO-1.0.1. File locking works in SO5.2
and I've given you another clue in that is works in OO when using 5.2
files - but not the new OO ones.

[Please also check the file mask? Make sure you chmod 666 before
trying this as for sure you can't read other poeple's files.]

I've played a bit more with locking...

File locking works for me in OpenOffice 1.0.1 with
'.sdw' '.sdc' '.doc' '.xls' files (i.e. StarOffice 5.x and MS formats). 

But, it does *not* work with '.sxw' and '.sxc' files (i.e. the new
StarOffice 6.0 or OpenOffice 1.0 formats).  That appears to be a
bug.

James, what file formats did you use for your tests when the
locking failed?
  

Excellent, we are making progress (and I'm not going potty!).

Yes, that appears to be it. Initially I used OO formats with OO as one
would but to check that I knew what to look for I used 5.2 for an
initial base line test, indeed 5.2 can lock files. I did this again
today but today when I tried OO this time I used the same 5.2 sdm file
for the OO test - and it locks. Perhaps I make a mistake I think, I'll
do exactly what I did the first time, using an OO file and success (or
failure!) it doesn't lock.

This is very odd as it must be the OS doing the lock; the file type
should make no difference.  Maybe the zip file is locked but you
unpack it to read and the contents looses the lock.

James.

Hmm, this is probably due to the use of ZIP format for these new
OO file formats.  OO has to unzip them before it can get at the real
file contents. Once unpacked the orignal ZIP is not needed any more
and is probably closed. If that theory is correct, it would loose the
locks placed at "operating system" level on the ZIP file as well.


Checking with 'lsof' on an OO 1.0.1 running with locking enabled,
after opening both a file 'foobar.doc' and 'foobar.swx', I see:

% /usr/local/etc/lsof -p `pgrep soffice` | awk 'NR < 2 || /foobar/'
COMMAND     PID USER   FD   TYPE        DEVICE SIZE/OFF    NODE NAME
soffice.b 12386   jk   31r  VREG       266,546     5136      34
/home/tiger.ebgen/tmp/foobar.sxw
soffice.b 12386   jk   32uW VREG       266,546     8192      49
/home/tiger.ebgen/tmp/foobar.doc


The '.doc' file is opened for "update (read/write)" and there's a
write lock visible in the FD colum.  But the '.swx' file is opened
read only and has no locks!

Problem is known and reproducible. This affects 641 builds like the OO
1.0.1. and has already been fixed in an internal 643 build which will
hopefully be the base for the next available OO-version. 

I have the same problem under Windows XP Pro accessing a (linux) Samba share. I have 
tried the locking with .sxc, .sxw, .xls, .doc and .sdw, and the problems only occurs 
with the .sxc/.sxw-files.
It has nothing to do with the extension itself (renaming 
the .sxc to .xls and vice versa makes NO difference), but with the file 
format.

Thorsten said, that the error is fixed in 643. Does this also apply to the 
other OSs or Solaris only?
Perhaps the OS field should be changed to "All"?!

This bugfix affects all OS, therefor OS-field is set to ALL !

*** Issue 1164 has been marked as a duplicate of this issue. ***

Hi There,

I have tried build 643 and it works nicely in that - I couldn't tell 
if this means that it will be fixed in the next 1.0.x stable release.

It seems to me that this is quite an important defect. I have 2 
companies evaluating OOo and one already moved across. For all 3 the 
only major issue with OOo is this flaw. For myself or a small company 
I could just go build 643 but for a corporate it's only possible to 
consider the stable releases.

It would be really cool if you could get a fix for this into the next 
stable release...

Thanks a Lot.

Regards,



Brian Powell

It is working for me in 643C.

Is there a reason why the status and target milestone hasn't been
updated on this issue? I would've thought this would be a good fix to
ensure it makes 1.1 Beta?

Is this in 1.0.2? I know it is NOT in 1.0.1 and IS in 643C, but how
can I tell if it made it into 1.0.2?

I have tested 1.0.2 and as far as i can tell it's not fixed.

.sxc and .sxw are still opened for READ only.

It would be nice to have this fixed in a 1.0 stable.

brianp - if the files are opening for READ ONLY then it IS fixed in
1.0.2. The problem is when the files were NOT locked in any way,
allowing many people to simultaneously edit the same file without any
knowledge others were doing so. You previously tested in 643C (as I
have) - is the function the same or different?

This issue affects all OS and all OO 1.0.x builds (based on a 641
build) like 1.0.1 or 1.0.2.. It has already been fixed in an internal
644 build and will therefore also be fixed in a OO 1.1 Beta.
So this issue is closed.  

*** Issue 11768 has been marked as a duplicate of this issue. ***

*** Issue 11768 has been marked as a duplicate of this issue. ***

*** Issue 11768 has been marked as a duplicate of this issue. ***

Please do not add duplications of duplication notifications ;)

Verified in OOo 1.1 Beta2.

closed ...

*** Issue 11858 has been marked as a duplicate of this issue. ***