https://bz.apache.org/ooo/show_bug.cgi?id=125194
--- Comment #13 from Giuseppe Castagno (aka beppec56) <[email protected]> --- After some months of work, I came up with a possible solution for this issue. The repository I use is on Github, a fork of the AOO mirror repo, link: https://github.com/beppec56/openoffice We needed to test using a stable release as a code base so we based all the work on AOO vers. 4.1.1. A description of what happens under the hood ============================================= On Windows 7 there is a driver installed, Windows MiniRedir (called Web Client service), that is used to carry out the low interface work with WebDAV. With some limitation, since it seems to work only with Sharepoint WebDAV, and not, for example, with Apache WebDAV. In the case described by this issue AOO tries to access the UNC provided (ex. \\server\shared-resource\file-to-open.doc) using the local filesystem. Observing the Wireshark log we registered, it appears that Windows tries to access the remote share first using Lanmanager protocols (SMB) then by using the Web Client service. The Web Client service checks the remote share to see if it lives on a Sharepoint server, in this case it takes care of the handshaking and perform all that is needed to manage the resource on WebDAV, while presenting it to the requesting application, in this case AOO, as it where a local file system resource. What originate the AOO behavior is a missing Windows API error management in sal/osl. To fix this specifically, I added the unmanaged Windows API error ERROR_FILE_CHECKED_OUT, treated as a file locked situation. I added the necessary code to manage it in ucb project as well. A side effect is AOO trying to use its lock file, but this is not possible, since the tilde '~' at the beginning of the private lock file prevents the file creation on WebDAV. To disable this behavior, I changed a default setting of the flag UseDocumentOOoLockFile in configuration and added a Windows API error not managed: ERROR_INVALID_NAME. The '~' side effect disabled above is managed adding a new Windows API error: ERROR_INVALID_NAME. I don't know if the configuration setting change impacts on AOO behavior, on current use it seems it doesn't. It seems that this change enables AOO to honor the lock MS Office Word put on a file it opens when working locally, allowing interoperability of Word with Office using the standard Windows file system. I checked the patch only in Windows 7 using Word from Office 2010, the patched AOO trunk version and Sharepoint 2013. I'm not sure how it works with different versions of Office. In Windows XP doesn't work, because in XP the Web Client Service seems quite different from the one installed on Windows 7. A patch containing the two changes, rebased onto trunk (r1677190) follows. -- You are receiving this mail because: You are the assignee for the issue.
