Description of problem: When saving a file in libreoffice, using the mounted gvfs-path, the following error occurs. Libreoffice cannot get closed then and needs to be killed in the shell. Errors: "Error saving this document: the file doesn't exist" and then after OK, this "Error saving this document: general error. general i/o-error" -> Saving to /run/user/[userno.]/gvfs/ works!! Version-Release number of selected component (if applicable): Version 3.6.3.2 (Build ID: 3.6.3.2-8.fc1 How reproducible: Always Steps to Reproduce: 1. Open Libreoffice, create any new file 2. save file to a share using gvfs (preferable on a samba-share) 3. Get the error Actual results: Cannot save file to this path. Expected results: Saving File to the Path indicated in the save-as-path-dialogue to the left. Additional info:
caolanm->sberg: is the a dup of the X-GIO-NoFuse=true issue or something else ?
Does the problem go away when you select "Tools - Options... - LibreOffice - General - Open/Save dialogs - Use LibreOffice dialogs" first?
i have changed this in libreoffice, now 2 situations occure: Prerequisite: i saved the samba-share as a favourite within libreoffice in the open/save-dialogue i always open a file within nautilus and want to save it. 1) i save clicking on the favourite folder and type a filename: The error comes up as described above 2) i use the path, which libreoffice seems to have and points to the local resource /run/user/100n/gvfs/[share] - this works and if i open the file within libreoffice without nautilus, both described situations 1) the same, it won't save 2) the same, it saves. it works always using the path from /run...
and no, it doesn't go away.
(upstream fix is <http://cgit.freedesktop.org/libreoffice/core/commit/?id=8722f0e7ef690205d042c8a6b1fdf342a34ecbe1> "rhbz#895690: Make GIO UCP less brittle, so saving docs works again")
libreoffice-3.6.5.2-7.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/libreoffice-3.6.5.2-7.fc18
Package libreoffice-3.6.5.2-7.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libreoffice-3.6.5.2-7.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-3868/libreoffice-3.6.5.2-7.fc18 then log in and leave karma (feedback).
Installed, tested and left posivite karma. Thx!
libreoffice-3.6.5.2-8.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/libreoffice-3.6.5.2-8.fc18
libreoffice-3.6.5.2-8.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 926001 has been marked as a duplicate of this bug. ***
On problem with this fix, in the past I could use the recent list to load files on a gvfs mount and it would automount it (ask for a password if needed). With this fix, that doesn't work. I do not know if you can cause the mount from file/open or not. I have had to just use nautilus to go to the mount and get it mounted, then the recent list works.
(In reply to comment #12) > On problem with this fix, in the past I could use the recent list to load > files on a gvfs mount and it would automount it (ask for a password if > needed). With this fix, that doesn't work. Are you sure that this got broken with this fix (i.e., did it still work with libreoffice-3.6.5.2-6.fc18)?
I am not sure what version it worked with. It was working with several versions post Fedora 18 release. It doesn't work now. It would be helpful if it did, but if it can't be fixed, I can understand that.
(In reply to Trever Adams from comment #12) > On problem with this fix, in the past I could use the recent list to load > files on a gvfs mount and it would automount it (ask for a password if > needed). With this fix, that doesn't work. > > I do not know if you can cause the mount from file/open or not. I have had > to just use nautilus to go to the mount and get it mounted, then the recent > list works. Turns out I forgot about this but later re-discovered the problem and fixed it on upstream master towards LibreOffice 4.2 as <http://cgit.freedesktop.org/libreoffice/core/commit/?id=4d8bf09305fc4e4bd652187aac0a02398413ba65> "Always try to mount in gio::Content::getGFileInfo" (no idea when exactly it got broken, though). Anyway, will be fixed in the next libreoffice-4.1.1.1-3.fc19.