Download it now!
Bug 41226 - FILEOPEN: not possible in File Explorer from own user network location
Summary: FILEOPEN: not possible in File Explorer from own user network location
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.6.2.2 release
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:4.2.0 target:4.1.0.1 target:4.0.5
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-26 05:59 UTC by fdlm82
Modified: 2013-08-02 03:59 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description fdlm82 2011-09-26 05:59:08 UTC
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
Comment 1 Rainer Bielefeld Retired 2011-09-27 21:57:40 UTC
[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 -
Comment 2 Björn Michaelsen 2011-12-23 13:24:53 UTC
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.
Comment 3 fdlm82 2012-10-18 18:28:03 UTC
this problem persist in all L.O. versions for windows.
Comment 4 Isamu Mogi 2013-06-06 00:00:55 UTC
Pending review:
https://gerrit.libreoffice.org/#/c/4151/
Comment 5 Don't use this account, use tml@iki.fi 2013-06-06 05:53:17 UTC
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;)
Comment 6 Commit Notification 2013-06-06 13:16:56 UTC
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.
Comment 7 Commit Notification 2013-06-10 09:06:06 UTC
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.
Comment 8 Commit Notification 2013-06-10 09:14:48 UTC
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.