<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - implement native KIO support to avoid potential data loss when using Dolphin file browser in SMB shares to open documents" href="https://bugs.documentfoundation.org/show_bug.cgi?id=119429#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - implement native KIO support to avoid potential data loss when using Dolphin file browser in SMB shares to open documents" href="https://bugs.documentfoundation.org/show_bug.cgi?id=119429">bug 119429</a> from <a class="email" href="mailto:nate@kde.org" title="Nate Graham <nate@kde.org>"> Nate Graham</a> <pre>(In reply to Buovjaga from <a href="show_bug.cgi?id=119429#c3">comment #3</a>) > (In reply to Nate Graham from <a href="show_bug.cgi?id=119429#c2">comment #2</a>) > > 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: <a href="https://cgit.kde.org/kio.git/commit/?id=820f622e86bb0b7d44a39a3f90f84c99736b30c7">https://cgit.kde.org/kio.git/commit/?id=820f622e86bb0b7d44a39a3f90f84c99736b30c7</a> 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>