Issue 53607 - File locking does not work with a new document.
Summary: File locking does not work with a new document.
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: 680m122
Hardware: Sun Solaris
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2005-08-22 11:22 UTC by tora3
Modified: 2017-05-20 10:47 UTC (History)
3 users (show)

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


Note You need to log in before you can comment on or make changes to this issue.
Description tora3 2005-08-22 11:22:43 UTC
Could you forward this issue to the appropriate project?


Current implementation seems not to work with a new document or 
a Saved-As document.

Could you consider the following topics?
 - Looking a document file when saving a new document.
 - Releasing a file looking when a document is saved as another file.

Scenario I

 (User A)
   1. Create a new document.
   2. Edit it.
   3. Save it. (Stay it opened.)

 (User B) 
   4. Open it.
      Expectation: It should be opened in the read-only mode.
      Reality:     It is opened in a normal mode.
   5. Edit it.
   6. Attempt to save it into the same file.
      Expectation: The attempt could be denied.
      Reality:     The existing file owned by user A is replaced by User B.

 (User A)
   7. Modify the document in the same window as in step 3.
   8. Attempt to save it.
      Expectation: No error occurs. 
      (From user A's point of view, he created, saved, edited, and saved it again.)
      Reality:     An I/O Error occurs.

Scenario II

 (User A)
   1. Open an existing file.
   2. Edit it.
   3. Save it as a new document file. (Stay it opened.)

 (User B, A)
   The same steps from 4 to 8 above.

 (User B)
   9. Edit it again.
  10. Save it as another document file.
      (Being asked not to tamper, user B changed a filename 
       of the document.)
 (User A)
  11. Attempt to save it into the first document file.
      Expectation: Now that, no error occurs.
      (User A was told that user B had changed a file name 
       of the document.)
      Reality:     An I/O Error occurs again.
Comment 1 matthias.huetsch 2005-09-05 13:50:00 UTC
Hi Mathias,

can you please have look at this issue?

Comment 2 Mathias_Bauer 2005-09-05 17:19:10 UTC
Mikhail, is it possible that the stream of the storage created in the save
operation is not locked correctly? In this case this issue qualifies for the
target 2.0.1.
Comment 3 mikhail.voytenko 2005-09-06 17:28:07 UTC
The stream retrieved on storing from UCB is not closed after saving. Thus it
seems to be a problem of locking on solaris.
Comment 4 mikhail.voytenko 2005-09-07 10:38:36 UTC
MAV->HRO: Could you please take a look as discussed. The important thing in the
provided by user scenario 1 is that saving of the new document by the user A
must be done to a nonexisting file. If it is done to an existing file the
locking seems to work well.

In case of nonexisting file the file is first created by SimpleFileAccess
service and then opened for writing. Creation of the file in file UCP currently
does not call File::sync() method, but adding of this method didn't help in my case.
Comment 5 hennes.rohling 2006-02-15 16:13:56 UTC
@mav: As discussed back to you. Try to find out wether closing the file after 
creation and reopening works. If so this would be an indicator that there's a 
problem with the NFS lock implementation on Solaris.
Comment 6 mikhail.voytenko 2006-02-27 10:48:12 UTC
I have checked one more time,  the stream that should lock the file is defenitly
not closed by the document. 

Strange enough, closing of the target file after creation and reopening does not
help, the file is still not locked correctly afterwards. But if the document is
saved second time to the same location the correct lock is set.
I have tried to sync the stream before closing, to reopen it multiple time.
Nothing helps. So it looks like the second storing of the document triggers an
action that let the document be locked correctly.

By the way, the problem is reproducible even with local volumes.

MAV->HRO: Could you please take a look.
Comment 7 mikhail.voytenko 2006-02-27 11:04:07 UTC
As we have discussed, it could also be that a kind of asynchronous mechanics is
involved, but at least a simple introducing of the sleep(30) call between
closing the stream and reopening does not help.
Comment 8 hennes.rohling 2006-04-26 16:30:35 UTC
I can't find any reason why creating a file, close it and reopen it with a write
lock should behave different than opening an existing file and setting a write
lock because when the file is reopend in the first case it already exists.

Sorry, no idea.
Comment 9 mlebek 2006-11-07 19:32:02 UTC
same behaviour on my gentoo system (kernel 2.6.11, OO 2.0.2)
Comment 10 hennes.rohling 2007-02-05 13:26:39 UTC
Comment 11 kai.sommerfeld 2008-02-04 14:20:33 UTC
Sorry, no time to fix this in 2.x time frame.
Comment 12 kai.sommerfeld 2009-07-13 12:44:24 UTC
mav: Please take over.
Comment 13 Marcus 2017-05-20 10:47:31 UTC
Reset assigne to the default "".