Issue 95608 - OpenOffice 3.0 does not handle file locking correctly for non-ODF documents or previous OOo versions - possible data corruption
Summary: OpenOffice 3.0 does not handle file locking correctly for non-ODF documents o...
Status: CLOSED DUPLICATE of issue 91015
Alias: None
Product: Calc
Classification: Application
Component: editing (show other issues)
Version: OOO300m9
Hardware: PC Windows Server 2003
: P2 Trivial with 1 vote (vote)
Target Milestone: ---
Assignee: spreadsheet
QA Contact: issues@sc
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-29 20:08 UTC by eclypse
Modified: 2008-11-02 20:41 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description eclypse 2008-10-29 20:08:01 UTC
If we have two users A and B, both with OOo 3.0 opening a Microsoft .xls or .doc
or whatever file on a Windows or Samba share, they can both open it R/W and
neither will know the other has it open. Both can update/overwrite each others
files and get no warning this has happened.

Similarly, if user A has 00o 2.x, and user B has OOo 3.0, this behaviour is
shown opening native ODF files or .xls, etc. files. User B opens the file as
R/W, user A can also open the file R/W. Both can overwrite each others data and
never know it has happened.

If an Excel user has an .xls file open, the OOo 3.0 user can open the file R/W,
make changes, but is then unable to save the changes without doing a Save As
(shows general I/O error).

When testing, I tried multiple settings for file locking with the Samba share,
but was unable to come up with anything that would alleviate this behaviour.
Standard setup for us is oplocks = yes, level 2 oplocks = yes, veto oplocks on
.xls files (tried with this off and made no difference), strict locking=no
(tried with this option as yes and made no difference), csc policy = manual
Comment 1 Stefan Weigel 2008-11-02 20:40:43 UTC
Duplicate of issue 91015


*** This issue has been marked as a duplicate of 91015 ***
Comment 2 Stefan Weigel 2008-11-02 20:41:45 UTC
Closing duplicate.