Hi Mikhail, Mikhail Voytenko wrote: > I think I see the problem. Probably you have exactly the case when file > system locking does not work. And the current implementation checks > whether the file was changed only if system file locking is not used by > the document. That is of course a bug, actually the OOo locking > mechanics was introduced to workaround the known problems with the > system file locking, so the check should be active always. I have just > submitted a new issue to myself > http://qa.openoffice.org/issues/show_bug.cgi?id=102701
You mean this? http://www.openoffice.org/issues/show_bug.cgi?id=102931 By the way, there would be some ways to confirm if a target file has been modified. (a) time stamp of a target file (b) digest value of a target file (c) original content of a target file As you know, Subversion is not using (a) to find modified files. 1. A programmer checks out source files from a repository. 2. He edits one of the source files and save it. 3. "svn status" reports "M filename" meaning "the file is locally modified." 4. He edits it again and "undo" the modifications and save it. 5. "svn status" reports nothing meaning "no file locally has been modified." Through the steps above, a time stamp of the file has been definitely changed. But, its content at the step 5 is the same as the original at the step 1. A criteria of "modified" could be reconsidered. As time goes, there would be more and more heterogeneous computing environments surrounding users. Somewhat unconvincing scenario: 1. A user downloaded (or checks out) her document file from the Internet disk yesterday. 2. Today, she starts editing the file with OpenOffice.org. 3. She downloads it again since she forgets when she downloaded it and ensures she has the latest one. 4. She attempts to save current document on the OpenOffice.org to the file. 5. She faces ... On the step 5, what should happen? A) A dialog window appears with a message: "The file has been MODIFIED after you had loaded the file" (in fact, the content of the file has not changed, though) B) Nothing happens since the content of the file has NOT CHANGED, even its time stamp has been changed, and she successfully saves the document to the file. I am not sure that which is better for current the generation of users: (A) comparing a time stamp of the file to determine modifications (B) comparing contents of the file to determine modifications But I bet (B) would be better for the future.
By the way, "SAL_ENABLE_FILE_LOCKING" does only affect sal implementation. So if it is not set the framework and office implementation still believes that the system file locking is used, at least the implementation requests sal to use it ( actually this variable looks to be a hack for me ). To let the framework not use the system file locking, there is a configuration entry "/org.openoffice.office.Common/Misc/UseDocumentSystemFileLocking", that let framework request no system file locking from sal for documents.
I would give it a try on a local file system using physical disk devices. Regards, Tora --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
