Apache OpenOffice (AOO) Bugzilla – Issue 53607
File locking does not work with a new document.
Last modified: 2017-05-20 10:47:31 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.
Hi Mathias, can you please have look at this issue? Thanks, Matthias
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.
The stream retrieved on storing from UCB is not closed after saving. Thus it seems to be a problem of locking on solaris.
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.
@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.
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.
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.
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.
same behaviour on my gentoo system (kernel 2.6.11, OO 2.0.2)
.
Sorry, no time to fix this in 2.x time frame.
mav: Please take over.
Reset assigne to the default "issues@openoffice.apache.org".