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!
> 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/
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.
(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.
(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.
Setting to NEW per -dev channel discussion.
With Frameworks 5.51, I can confirm that now the overwrite prompt appears when saving with LO on Samba. Thank you, guys!
Awesome. Hopefully by 5.52, it will overwrite automatically without that annoying confirmation prompt. See https://phabricator.kde.org/D15318
Anyway, the original issue as described here was fixed with upstream changes in KDE Frameworks.
Very nice. Does this also apply to the Dolphin prompt that appears as well?
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.
Seems like that PR has gotten stuck?