Problem description: when try to open an odt or ods file on a network share (from \\server\folder\namefile.odt) the libreoffice logo appear but the file does not open. If I copy the file locally or on a network drive mapped, the file is opened correctly. Ms Word/Excel open the file correctly The file server is Windows 2008R2 Enterprise Steps to reproduce: 1. Sart-Search 2. Type the network path (Ex: \\server\folder\) 3. Double click on file Current behavior: Expected behavior: Operating System: Windows 7 Version: 4.1.3.2 release
Please check with 4.1.4 pre-release version as this bug is probably fixed: http://www.libreoffice.org/download/pre-releases/ Do not hesitate to reopen in case of mistriage. *** This bug has been marked as a duplicate of bug 67534 ***
Libreoffice 4.1.4.1 still have this bug. The Windows Explorer extensions is not installed.
Never confirmed - moving back to UNCONFIRMED.
LibreOffice 4.2.7.2 on Ubuntu platform still have this limitations.
(In reply to Walter from comment #4) > LibreOffice 4.2.7.2 on Ubuntu platform still have this limitations. To bypass this bug comment into /usr/share/applications/libreoffice-*.desktop the line X-KDE-Protocols=.... I have no idea if this could open furhter limitations or not. This is a WORKAROUND to open files shared with smb protocol on linux platform.
I have just updated from LO 3.6 to LO 4.3.5 on a Windows XP SP3 machine and I cannot open any files through network with LO anymore. I get the following errors: "C:\WINDOWS\TEMP\lurjbk7.tmp\lurjbk9.tmp does not exist" "Object not accessible. The object cannot be accessed due to insufficient user rights" If I move those files to a local folder, I can open, edit and save without problems. But If I move back this file to a network folder I can't open it. If I open the files as read-only, it opens with no issues. I have downgraded to 4.2.8.2 and not install explorer extensions and I get the same problem. I have tested on another PC with Windows 7 and LO 4.1.4.2 and I also get the same problem. The network server is a Orange LiveBox DSL Router with an external USB FAT32 Hard Disk attached. Any place to download latest LO 3.6 meanwhile?
http://downloadarchive.documentfoundation.org/libreoffice/old/ If you actually are willing to test lots of versions it would be nice to figure out the exact version where things went wrong...I know it's a lot of work but it could potentially help us identify the commit that caused the problem.
Ok. I'll do it. I have tested with the same computer with Win7+LO 4.1.4.2 on a different network share at work (Windows Server) and it works smoothly. However if I drop the same file on my home network share, I get the error, so it affects, at least, to LO 4.1.4.2 and newers on **some** network shares. I can reproduce the error even mounting the network share with a drive letter (Z:) LO 3.6 worked fine on that shared folder. Other software (like MS Office, Photoshop, etc.) doesn't have any issue. I'm going to look out the last version which work here and let you know. PS: Should I change the UNCONF status?
Sure I'll go ahead and set this as NEW per comment 6. If you're able to identify the exact release (or beta/alpha/rc) that caused the problem, please set that as the version (version is the oldest version that the problem is confirmed on). Thanks for the help! Feel free to come join us in the QA chat if you have questions or just want to chat: http://webchat.freenode.net/?channels=libreoffice-qa
I've been checking with the following portable editions: 4.1.2, 4.1.3 and 4.1.4 The problem arise on 4.1.4, so I'm installing 4.1.4.1 to check if it is on RC1. I think that the problem comes from this commit: http://cgit.freedesktop.org/libreoffice/core/commit/?id=3d12549335229aca1a6a57575292111274709992 After looking the comments on bug #70345 (where this commits comes), I see that it can affect to older versions also. So you want me to test any other specific version (like 4.0.4) let me know.
I have installed 4.1.4.1 and it also fails, so I'm setting 4.1.4 as version field.
Version is the oldest version that shows the problem - not the latest tested on. We just use comments to say it's still an issue. Reverting last change.
Also this is not a critical bug - critical is loss of data, crashes, or loss of functionality that would impact the majority of our users. Although this is pretty bad - it's not going to affect the majority of users. Lowering to Major. Lastly, it would be nice to figure out when the regression actually happened. For anone seeing this issue if you could test older versions and let us know exactly what pre-release started showing the issue (and the last known version that did not have the issue) that would help to narrow the issue down. http://downloadarchive.documentfoundation.org/libreoffice/old/
Hi Joel, Probably you didn't read my comment #10. I have already tested the following portable editions: 4.1.2 -> NOT FAIL 4.1.3 -> NOT FAIL 4.1.4 -> FAIL So I can confirm that the problem arise on 4.1.4.1 I'm agree that this problem is not critical. It was set by who opened this bug. Regards,
I'm on Ubuntu 12.04.5 with all updates and LibreOffice Version: 4.4.1.2 Build ID: 40m0(Build:2) (libreoffice 1:4.4.1~rc2-0ubuntu1~precise1) from PPA. What I did: 1. I have shared my Public folder using nautilus-share (0.7.3-1ubuntu2), placed test.odt file in it. 2. I navigate Nautilus to smb://localhost, and double clicked on test.odt file. 3. 'LibreOffice 4.4' dialog opened with text: "The file 'test.odt' is corrupt and therefore cannot be opened. LibreOffice can try to repair the file. The corruption could be the result of document manipulation or of structural document damage due to data transmission. We recommend that you do not trust the content of the repaired document. Execution of macros is disabled for this document. Should LibreOffice repair the file? Yes No" 4a. If I click 'Yes', the file is opened, but the title of the document is "Untitled 1 (repaired document)", not original name. 4b. If I click 'No', the dialog 'LibreOffice 4.4' is opened with text: The file 'test.odt' could not be repaired and therefore cannot be opened. OK" I click 'OK' here, the next window "LibreOffice 4.4.1.2" is opened with text: "General Error. General input/output error. OK" If I click OK here - no files are opened. This functionality is essential. Please fix this bug. I (and you) can't tell Windows users, that they should not open office files from network shares in GNU/Linux.
Bug exists in LibreOffice "Version: 4.3.6.2 Build ID: 430m0(Build:2)" (1:4.3.6~rc2-0ubuntu1~precise1).
Hello Norbert, I think that we might be reporting two different bugs here. Could you try that with LibreOffice 4.1.3? If that version works for you, probably we are experience the same regression bug. Regards,
So - what would be nice is if someone experiencing this bug can start trying to bisect it. This means learning how to build and figuring out what commit (or range) let to the problem. As is, we have no idea what commit broke it and it's been so long that it could literally be tens of thousands of commits. For someone who really wants it fixed, please build LibreOffice on Windows and slowly start narrowing down what commit broke it. This is likely going to take hours (or days) but it'll get the bug closer to being resolved. For help feel free to join: http://webchat.freenode.net/?channels=libreoffice-qa or http://webchat.freenode.net/?channels=libreoffice-dev
Hello Joel, I confirm that the bug it also reproducible on 4.4.0.3 I set back the version on 4.1.3.2 as per comment #10
I did some research with different versions of LibO and on different distros. The test method was as follows: I set Samba public share on my other laptop, created document in this share, then connect to it. Here is a Google Docs Table ( http://goo.gl/jY9Ubj ): * I got message about repairing only in 12.04.5 with LibO 4.x * In other distros I got 'Document in Use' very often. After this research I can't determine why 'Document in Use' message is produced.
I am currently building LibreOffice on Windows, after I do, I'll remove the possible problematic commit and build a new msi file. Once I do this I'll post a link to it so you guys can't test it. If we can confirm that it's the issue, then we can at least determine if we want to revert the commit or not (I'm not entirely sure what it resolved)
I've built a msi that does not contain the commit, you can find it here: https://drive.google.com/file/d/0B2kdRhc960qda096M1ZteDgyYzg/view?usp=sharing Please test and report back. If this resolves the problem, I will talk to Michael about reverting the commit (or getting it fixed). Thanks for your hard work helping to track this down.
Dear Joel! Thank you for your MSI. I tested it on Windows 7 x64 - with shared folder from Windows 7 x32 SMB/CIFS server. It works as expected with Windows SMB/CIFS server - all versions which I tested (3.4.5, 3.5.7.2, 3.6.5, 4.0.4, 4.1.6, 4.2.8, 4.3.6, 4.4.1, your 4.5.0dev) opened test odt-file without errors (using UNC address, or mounted share). If I use Samba 3.6.3 on Ubuntu 12.04.5 as SMB/CIFS server I get errors 'Document in Use' on Windows and GNU/Linux clients. So for me it seems that there is a difference in communication between Samba SMB/CIFS (or Windows SMB/CIFS) server and LibreOffice. I do not know how to debug this. Both SMB/CIFS servers provide full read and write access on file level (via GVFS and mount.cifs). Samba SMB/CIFS share was created with nautilus-share addon, without any error messages and non-standard configuration. My results are summarized in Google Docs table ( http://goo.gl/jY9Ubj ).
So now I'm a bit confused. But my general takeaway from the last comment is that the msi I provided did not resolve the issue - is this correct? In which case - it's not that commit that caused the regression
Joel, in my configuration I can't confirm original issue while using Windows as SMB/CIFS server. >It works as expected with Windows SMB/CIFS server - all versions which I tested >(3.4.5, 3.5.7.2, 3.6.5, 4.0.4, 4.1.6, 4.2.8, 4.3.6, 4.4.1, your 4.5.0dev) >opened test odt-file without errors (using UNC address, or mounted share). Let's wait for response from AntonioGM. Dear AntonioGM! You can use my Google docs table ( http://goo.gl/jY9Ubj ) for saving test results. If you are going to use other SMB/CIFS (not Ubuntu 12.04.5 and not Windows 7) please use sheet "other SMB/CIFS server".
Doesn't that test just show that it always worked? You said it worked on every version - so I'm trying to figure out where the regression was given your data :-/ Sorry I'm just confused as to where we are in the process.
Definitely we are talking about different bugs. I have tried the building that Joel has made and it WORKS. So the that Joel rolled back caused a regression bug on 4.1.4 that make LO to fail when opening files on CIFS. I want to recall that my network share is a Orange LiveBox 2.1 DSL Router with an external USB FAT32 Hard Disk attached.
Adding Kendy to see what he thinks about reverting that commit. Kendy - can we revert this commit? Or is there some way to fix it so that this regression can be put to rest? http://cgit.freedesktop.org/libreoffice/core/commit/?id=3d12549335229aca1a6a57575292111274709992
Dear AntonioGM! From my tests with Windows SMB/CIFS server it seems that we do not need to revert any commits. It works as expected with all versions of LibO (see my table). I do not know what is OrangeBox, but from OpenWRT page [1] it seems to be MIPS-based router. So it uses Samba for NAS functionality very likely. In comment 6 you had broken LibO installation. Client - WinXP SP3, server - LiveBox. In comment 8 you have other test configuration. Client - Win7, server - Win Server (version?). In comment 10 you have another test configuration - you use portable editions. But portable editions are not integrated to Explorer. Client is Win, server - unknown. In comment 11, 14, 19 you use other LibO versions. Client - Win, server - OrangeBox(?). Could you please perform comprehensive testing as I did? By 'comprehensive' I mean same SMB/CIFS server, same client, different versions of installed (not portable) LibO. Did you update the firmware on OrangeBox between comments? Please fill the 'other SMB/CIFS server' (from row 3, columns N and O) sheet in my table. Otherwise we would apologize for lost time on compilation, spent by Joel. 1. http://wiki.openwrt.org/toh/arcadyan/arv7519
@Norbert - There is no need for him to do a comprehensive test. It's sufficient that he sees the bug in one test environment, and then with the commit removed, he no longer sees the issue.
Hello Norbert, Qll the tests that led me to the right commit has been done on the same computer and SMB/CIFS server described on comment 6. I don't recall to have reported a broken LibO installation. However, as I was not sure whether the problem is on LO or on my system, I repeated the test with another computer (Windows 7), another CIFS server (Windows Server) and/or another software (MS Office) to learn that the the issue only happens on some CIFS servers and only on some LO versions (I have never stated any issue on Windows servers). So in order to guess which commit could be causing this, I repeated the FIRST test (the one which worked with LO 3.6 and stopped after upgrading to LO 4.3.5) with portable versions to guess the exact release where the problem appears. After all tests, I can confirm that the issue started on 4.1.4.1 and didn't dissapeared until the compilation made by Joel. On the other side, I have never seen any "Document in use" neither "broken file" error messages, so we are talking about completely different things. The fact that a commit works fine for you doesn't mean that will work for everyone else. I know that this doesn't happen on all Samba server, but if I'm experiencing on my DSL Router, this could be happening to others users too as this router is quite popular on Spain and France. My worries is that probably the right solution won't be just reverting this commit as it solved an issue to others too, so it could require a more complex solution. Regards,
AntonioGM, it's great that you are happy with the new build. I'm sorry if I understood or commented your comments wrong. I'm not happy with "Document in Use" (bug 89632) and "Should LibreOffice repair the file" (Ubuntu Precise-specific bug with massive package rebuild). But it's another story.
Sorry for repeating my last message twice. I had problems posting it. About our issues, now that it's confirmed that there is two different bugs, I think that this bug should be splitted if that make life easier to developers and QA. What do you think, Joel?
I completely agree :-D
Joel: You've added me in comment 28, but the patches in this area seem to be from Michael S., so I'm adding him, as I don't recall this area ATM...
Hey Kendy - Indeed - my mistake :-/ @Michael - we discussed this in the chat and now it's confirmed that the commit is the problem. Thoughts on reverting or fixing it?
CC: the original patch author of bug 70345 that introduced this regression; i'm considering reverting the patch...
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7c4415407f2df5460d3667aa9f820865a615f57f tdf#72337: sfx2: make the SfxMedium stream-reuse hack runtime-optional It will be available in 4.5.0. 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.
so given no feedback from Mathieu, ESC has decided to revert the change for now; or rather, by default we will do the same thing as in LO 4.1, the "new" behaviour can be enabled by setting an environment variable.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=09aa700793f3f1b3344558ea8a91b8f4134099de&h=libreoffice-4-4 tdf#72337: sfx2: make the SfxMedium stream-reuse hack runtime-optional It will be available in 4.4.3. 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.
Migrating Whiteboard tags to Keywords: (notBibisectable) [NinjaEdit]