Bug 119429 - implement native KIO support to avoid potential data loss when using Dolphin file browser in SMB shares to open documents
Summary: implement native KIO support to avoid potential data loss when using Dolphin ...
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All Linux (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-22 19:50 UTC by tempel.julian
Modified: 2019-04-08 16:37 UTC (History)
4 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 tempel.julian 2018-08-22 19:50:26 UTC
Browse an SMB share with KDE Plasma's recommended Dolphin file explorer and with it, open a document file in e.g. LibreOffice Writer.
The file gets opened correctly and it looks like it can be edited.
However, saving the edited file at the network location fails because LibreOffice uses Gnome's GIO, despite of running inside a KDE Plasma session.

This is especially nasty because the saving fails silently. The program makes the user think that the file was successfully saved, but when reopening the document, all the changes are lost.

This could be solved by adding native KIO support into LibreOffice.
See this ticket on KDE bugtracker:
https://bugs.kde.org/show_bug.cgi?id=397742

The KDE filepicker that comes with gtk3_kde5 VCL allows to successfully edit documents on SMB shares, but it doesn't help when opening the document out of Dolphin.

Thanks!
Comment 1 Nate Graham 2018-08-22 20:33:48 UTC
> The KDE filepicker that comes with gtk3_kde5 VCL allows to successfully
> edit documents on SMB shares, but it doesn't help when opening the document
> out of Dolphin.

From a technical point of view, what's happening is that the file picker is using KIO, as expected, and KIO knows how to access Samba shares. All is well there.

But when opening a document from Dolphin, Dolphin is executing `<app name> %U` (e.g. libreoffice-writer smb://path/todocument.odt). Because LO apps don't either use KIO or have a built-in Samba client, KIO intercepts the call, downloads the document from smb://path/todocument.odt to ~/.cache/kioexec/krun/<random number>/document.odt, and tells LO to open it from that path.

All is well so far. But starting in LO 6.1, upon saving the document and quitting, KIO does not get the signal that the file was saved, and so does not upload it back to the remote URL. This happens with GIO-using apps (I believe LO gained support for GIO recently, but correct me if I'm wrong).

We are working on the issue from the KDE side, but it would also work if LO apps gained native KIO support.

See also https://ask.libreoffice.org/en/question/23021/solved-open-ods-or-odt-files-from-a-smb-share-throws-damaged-file-error/
Comment 2 Nate Graham 2018-08-22 21:30:58 UTC
This could also be caused if suring the save process, LO deletes the old file and replaces it with a different one. This would be very unfortunate from a KDE perspective as we currently have no way to handle that.
Comment 3 Buovjaga 2018-09-10 19:19:49 UTC
(In reply to Nate Graham from comment #2)
> This could also be caused if suring the save process, LO deletes the old
> file and replaces it with a different one. This would be very unfortunate
> from a KDE perspective as we currently have no way to handle that.

From a recent discussion on #libreoffice-dev regarding another matter, I understand this is exactly the way LibreOffice does saving.
Comment 4 Nate Graham 2018-09-10 19:29:07 UTC
(In reply to Buovjaga from comment #3)
> (In reply to Nate Graham from comment #2)
> > This could also be caused if suring the save process, LO deletes the old
> > file and replaces it with a different one. This would be very unfortunate
> > from a KDE perspective as we currently have no way to handle that.
> 
> From a recent discussion on #libreoffice-dev regarding another matter, I
> understand this is exactly the way LibreOffice does saving.

Right. We discovered that LO performs atomic saves while investigating this issue.

We committed a fix to KIO to support apps that perform atomic saves like LO: https://cgit.kde.org/kio.git/commit/?id=820f622e86bb0b7d44a39a3f90f84c99736b30c7

That said, it would still be nice to get native KIO support as a part of the KDE backend. It makes a lot of other things nicer, too.
Comment 5 Buovjaga 2018-09-11 10:45:36 UTC
Setting to NEW per -dev channel discussion.
Comment 6 tempel.julian 2018-10-15 13:51:29 UTC
With Frameworks 5.51, I can confirm that now the overwrite prompt appears when saving with LO on Samba. Thank you, guys!
Comment 7 Nate Graham 2018-10-15 13:53:28 UTC
Awesome. Hopefully by 5.52, it will overwrite automatically without that annoying confirmation prompt. See https://phabricator.kde.org/D15318
Comment 8 Nate Graham 2018-10-15 13:55:28 UTC
Anyway, the original issue as described here was fixed with upstream changes in KDE Frameworks.
Comment 9 tempel.julian 2018-10-15 14:13:19 UTC
Very nice. Does this also apply to the Dolphin prompt that appears as well?
Comment 10 Nate Graham 2018-10-15 14:16:44 UTC
Yes, with https://phabricator.kde.org/D15318 the save workflow should be completely transparent: upon save, it will automatically re-upload the changed file without asking for confirmation first, just like all other save operations do.
Comment 11 tempel.julian 2019-04-04 10:22:23 UTC
Seems like that PR has gotten stuck?