Bug 39591 - KDE-Integration, can not save to remote fs supported by kio
Summary: KDE-Integration, can not save to remote fs supported by kio
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.4.2 release
Hardware: All Linux (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard: target:4.1.0
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-27 02:55 UTC by bug_freedesktop
Modified: 2014-10-08 09:08 UTC (History)
5 users (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 bug_freedesktop 2011-07-27 02:55:44 UTC
while it is possible to open files from KDE kio-supported fs, it is not possible to save them back
this is specially problematic, because it get's quietly saved in the local temp directory, which is "lost" at some point in time - and not easily accessible by users.
IIRC there was an deferred upload moving the file from temp to the original place, but this is not granted - especially in case of network failure or power off

or to save new documents
message: you can only select local files "Sie können nur lokale Dateien auswählen"

probably just a missing
X-KDE-Protocols=http,ftp,smb,fish
entry somewhere ? program/kdefilepicker ?

this happens both in official OpenSuSE and generic libreoffice rpms
Comment 1 Björn Michaelsen 2011-12-23 12:24:54 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 2 Florian Reisinger 2012-08-14 14:00:28 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 3 Florian Reisinger 2012-08-14 14:01:36 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 4 Florian Reisinger 2012-08-14 14:06:19 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 5 Florian Reisinger 2012-08-14 14:08:20 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 6 sasha.libreoffice 2012-09-29 07:08:59 UTC
> quietly saved in the local temp directory, which is "lost" at some point in time
now KDE asks about uploading this file to server after exiting LO.

> not granted - especially in case of network failure or power off
if any program will save file to network drive and happens network failure or power off, then file will be corrupted. This problem exist for all programs.

Main problem is that LO not allow wile names in URI notation, such as smb://server/user/file.odt. On Windows used shortened filenames, without smb: in beginnings. And it works. On Gnome all network drives mounted automatically to ~/.gvfs folder.

Possible workarounds: mount network drive manually (not useful if drives can be pover-off in different times); or use Nautilus

We may also ask developers to add support of  URI notation to LO
Comment 7 ferdinand 2012-10-30 21:00:08 UTC
Libreoffice does upload the saved file only AFTER closing all windows of libreoffice (excuse if this is not the technical correct wording)

it should upload immediately after clicking "save"

especially if using hibernate the libreoffice window is likely to never been closed hence the file never gets uploaded.

and I think the upload should occur without asking - only come up with an error message if upload is not successful ( I notice that this might be a performance issue if connected via slow lines)
Comment 8 sasha.libreoffice 2012-10-31 14:41:10 UTC
> Libreoffice does upload the saved file only AFTER closing all windows of 
> libreoffice
Thanks for warning about this problem. Me and other readers of this bugreport will be more cautious when using network.
Currently LO can not work with network at all. It is KDE workaround.
IMHO it is better to not edit network files at all. Just copy them to local drive and then edit. It is boring, but probability of information loss is much more low.
Comment 9 ferdinand 2012-10-31 16:14:37 UTC
other possibility is to mount the remote file system 

KDE is so tempting because fish is very fast compared to samba (at least my observation)
Comment 10 Marco Menardi 2012-12-30 17:50:08 UTC
At work me and my colleague have lost many times what we edited because if this. We have a samba share and is easy with Dolphin access it (i.e. I've created a "resource" in Dolphin that smb:// to the shared storage).
I've never seen LiBo "upload" the changes, seems to me that simply grabs the file from the lan, saves in a temporary file in a temporary dir and then saves it there, stop.
Grabbing the file locally, editing and then re-copy back can be done, but other KDE programs work just fine so you often don't remember, and in any case is troublesome.
If we care about one of most used DE in GNU/Linux this bug should be fixed and is a major problem since produces data loss until you notice.
Comment 11 Marco Menardi 2013-01-09 20:14:16 UTC
I've done some further test, since here I've found comments about KDE asking to transfer the modified file, while instead I've lost the content most the time.
Well, if you have LiBo open ONLY on the remote file, when you close LiBo it really asks you if you want to transfer it to the network share.
BUT this happens only if you close LiBo after saving a remote file, and transfers only it!
test cases, with r1.odt, r2.odt as remote files, and loc1.odt as local file
- if you open r1, modify it, save and close Libo: transfer
- if you open r1 and r2, modify both, save both, close r1, close r2, close Libo: transfers only r2 (r1 modifications are lot)
- if you open r1, loc1, modify and save both, close r1, close loc1: no transfer (r1 modifications are lost)
So seems that asks to transfer only if the *last* LiBo instance you close is about a remote file, other instances close silently on this regard.
Kubuntu 12.04, LiBo 3.6 AFAIR, maybe 3.5 (don't recall if I activated specific LiBo PPA to have the most updated version), sure a long standing bug since I've lost editings in the past.
Comment 12 Uwe Dippel 2013-04-08 12:00:51 UTC
This is a bummer. Really. How can this be 'open' for some years without activity? I am running Kubuntu 12.10, and find the same. Sometimes, the modifications are just lost, because stored in a tmp file/folder.
Even if the proper 'mount' cannot yet be done automatically, the user must be informed at opening and must be informed at closing, and must be informed at exiting.
Lost work without warning and without the user knowing nor guessing (the remote location looks mounted in Dolphin) must not happen.
Comment 13 Maxim Monastirsky 2013-10-21 08:58:34 UTC
(In reply to comment #12)
> Sometimes, the modifications are just lost, because stored in a
> tmp file/folder.
This part is already fixed by http://cgit.freedesktop.org/libreoffice/core/commit/?id=673be8e76856c6bc39f448f3374db4ae84258952. If it's not working for you with the latest 4.1.2.3, you're probably missing some packages - see Bug 67527 comment 29 (and also Bug 49776).
Comment 14 Maxim Monastirsky 2013-10-21 09:43:09 UTC
The above commit is included in 4.1, so marking as RESOLVED FIXED + target:4.1.0.

The message 'You can only select local files' which is mentioned in comment 0, is completely unrelated and should be discussed in a separate bug. The recently reported Bug 70712 is a good place for that.
Comment 15 Stephan Bergmann 2014-10-08 09:08:02 UTC
FYI, <http://lists.freedesktop.org/archives/libreoffice/2014-October/063904.html> "Re: X-KDE-Protocols=...,smb,...">:

"Unfortunately, the fact that Dolphin will communicate documents on smb shares with LO via /var/tmp proxy files again now (see above), will re-open [this bug] again---if you modify such a document in LO, Dolphin will ask you whether it shall upload it again only after you close LO (cf. <https://bugs.freedesktop.org/show_bug.cgi?id=39591#c6>)."