Problem description: create any LibO document in you OWN network location in Windows 7, then try to open the document and it show the LibO loading window and then nothing happend, the document doesn't open. Steps to reproduce: 1. create or paste a document (any) in \\myNetworkPCName\Users\Public 2. double click to the document - do not try to open in c:\Users\Public because it works - this happend in all versions of LibO 3.3.x and 3.4.x Current behavior: it shows the loading window and does not open the document Expected behavior: show the loading window and open the document
[Reproducible] with "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]" Steps to reproduce: 1. go to your own Network item in WIN explorer to the users path (for example on my PC "\\USER-PC\Users\user" 2. Into a free place in the right files pane: 'Right click -> New -> OpenDocument Spreadsheet' A new Document "OpenDocument Tabellendokument (neu).ods" (Gerrman name) will be created 3. Double click new Document Expected: will be opened in LibO Actual: Nothing (right click - open with won't work either) 4. Check "normal" path "C:\Users\user\" New document OpenDocument Tabellendokument (neu).ods" is visible 5. double click new document Will be opened as expected Further investigations: It has nothing to do with "New document" same problem with ODF documents existing in "C:\Users\user\" It has nothing to do with "user" area, same problem with ODF documents existing in "C:\Users\public\" Works fine from LibO- OS - File dialog I will check later whether there is a problem with documents network on other PC, but I believe I would have seen that. Funny thing: that new document has not been created with the correct "new document default" template, but with an other one I had temporarily defined as default for investigations for an other bug. I will file a new bug for that problem. @Tor: Might be WIN specific? Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug. - Reported with Bug Submission Assistant -
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
this problem persist in all L.O. versions for windows.
Pending review: https://gerrit.libreoffice.org/#/c/4151/
This bug shows that it is not a good idea to assign a bug to somebody else. Better to add that person to CC and *ask* if they might have any idea what the problem might be, etc. I have not done anything for this bug, nor did I have any immediate plans to. However, somebody looking at this bug might have mis-interpreted the "Assigned To" status and thought that "good, somebody is working on it, then I don't need to". Luckily Isamu Mogi did not. Thanks! So please, don't assign bugs to me in the future;)
Isamu Mogi committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6d2e3bdac27ade56031d930c85e906c0d35877bc fdo#41226 Add error handling of recursed GetCaseCorrectPathNameEx() The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Isamu Mogi committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d074556e5a62d3b0029babcb02a3b7955a9eb084&h=libreoffice-4-1 fdo#41226 Add error handling of recursed GetCaseCorrectPathNameEx() It will be available in LibreOffice 4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Isamu Mogi committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0a57644fd1ac197571c69cd3bbf67ec05c98dd74&h=libreoffice-4-0 fdo#41226 Add error handling of recursed GetCaseCorrectPathNameEx() It will be available in LibreOffice 4.0.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.