Version: unspecified (using KDE 4.5.1) OS: Linux When open file on remote storage (smb, ftp, sftp...) with application that don't support kio (OpenOffice.org for example), modify it and save back, file on remote storage isn't updated... Reproducible: Always Steps to Reproduce: put some file on writable remote storage (samba for example) and open this file with application that don't support kio. For example: kioexec oowriter smb://localhost/shared/test.odt And then, modify this file, save this and close application. Actual Results: modified file is saved only to /var/tmp/kdecache-$USER/krun but it is not transfered back to remote storage Expected Results: kioexec wait on background and listen on tmp file changes. when this file is changed, tranfer it back to original source. When transfer back isn't possible, make file in tmp read only. I am try this on Gnome. It makes things right way, but I don't know how Gnome works...
(In reply to comment #0) > Version: unspecified (using KDE 4.5.1) > OS: Linux > > When open file on remote storage (smb, ftp, sftp...) with application that > don't support kio (OpenOffice.org for example), modify it and save back, file > on remote storage isn't updated... > > Reproducible: Always > > Steps to Reproduce: > put some file on writable remote storage (samba for example) and open this file > with application that don't support kio. For example: > > kioexec oowriter smb://localhost/shared/test.odt Did you mean "kioclient exec smb://localhost/shared/test.odt" ? > And then, modify this file, save this and close application. > > Actual Results: > modified file is saved only to /var/tmp/kdecache-$USER/krun but it is not > transfered back to remote storage > > > Expected Results: > kioexec wait on background and listen on tmp file changes. when this file is > changed, tranfer it back to original source. > > When transfer back isn't possible, make file in tmp read only. > > I am try this on Gnome. It makes things right way, but I don't know how Gnome > works... Currently kioexec only uploads the changes when you close the application. I am sure there is a valid reason why it is done this way, but I dunno why ; so I will leave that for David to answer.
No, I'm pretty sure he means kioexec oowriter, this makes more sense :-) The problem is that the oowriter binary exits immediately, it doesn't wait for the window to be closed. So kioexec has no way to know *when* the editing is finished and the upload back should be done...
(In reply to comment #2) > No, I'm pretty sure he means kioexec oowriter, this makes more sense :-) > > The problem is that the oowriter binary exits immediately, it doesn't wait for > the window to be closed. > So kioexec has no way to know *when* the editing is finished and the upload > back should be done... Hmm... It must be specific to openoffice then because I cannot reproduce this with kioexec + libreoffice: kioexec lowriter sftp://<path>/<document>.odt When I close the application after modifying the document, I get the prompt to upload the changed document.
Now try again with libreoffice already running before calling kioexec :-) Then it will have the "kuniqueapplication-like" behavior of "talking to the running process and exiting immediately".
Hi all, I use gentoo linux in amd64 system and use with my de kde 4.7.4. I install gimp and everythink works, but when i editing one file in a smb:// directory on my lan server, gimp no save over the same file, but save the file in /var/tmp directory. When i close gimp, kioexec asking me if i want to bring change to the file, only when i close the program. If possible execute kioexec or other software to save changes in the remote file in real time? Any solutions or escamotage? Best regards Alessandro
Hi all, in my case if any of LibreOffice Programs (tested with Writer and Calc) is already running, all files open afterwards are not updated into Samba shares after last LibreOffice Program is finally closed (Case 1). Case2: If Libreoffice Program is not running before opening file, only first edited file is updated. Reproducible: Always Steps to reproduce Case 1: Open LibreOffice Writer Open two or three *.ods (Calc) files via Dolphin from samba share. Edit files and save changes, then close files in random order and close all LibreOffice Programs. Expected results: Kioexec asks about all changed files and propagates them to samba share based on user answers. Actual results: No kioexec prompts and no file is propagated back to samba share. Steps to reproduce Case 2: Make sure no LibreOffice Program is running. Open two or three *.ods files via Dolphin from samba share. Edit files and save changes, then close files in random order and close all open LibreOffice Programs. Expected results: Kioexec asks about all changed files and propagates them to samba share based on user answers. Actual results: Kioexec asks only about first file (one which opened corresponding LibreOffice Program). This file is propagated properly to samba share if user answer indicates so. Changes in other files are ignored. Sometimes I see message that original file has changed even though nobody was accessing it in the meantime. Not sure if this has any relevance to described bug. System up-to-date Kubuntu 10.10 64 with KDE 4.7.4, LibreOffice 3.4.4
Correction to comment #6 last line, up-to-date Kubuntu 11.10
Hi all, I use kubuntu 12.10 ( amd64 ) I install gimp and everythink works, but when i editing one file in a smb:// directory on my lan server, gimp no save over the same file, but save the file in /var/tmp directory. When i close gimp, kioexec asking me if i want to bring change to the file, only when i close the program. If possible execute kioexec or other software to save changes in the remote file in real time? Any solutions or escamotage? Best regards Alessandro
*** Bug 278319 has been marked as a duplicate of this bug. ***
+1 for this feature!
currently (Ubuntu 13.10, libreoffice 4.1.4.2) the files ARE uploaded, but only AFTER libreoffice WINDOW is closed. this is typically not what users do, they leave for lunch, open another file etc. the changed file often never gets uploaded. the user is usually not aware of this issue and complains about lost work. IMO it must be uploaded if the save button is clicked. To be discussed: intermediate saves ?
This should be enough to solve this issue once and for all: void QFileSystemWatcher::fileChanged(const QString & path) [signal] This signal is emitted when the file at the specified path is modified, renamed or removed from disk.
(In reply to comment #12) > currently (Ubuntu 13.10, libreoffice 4.1.4.2) the files ARE uploaded, but > only AFTER libreoffice WINDOW is closed. when connected via fish:// protocol, bug is still present in my Kubuntu 13.10, libreoffice 4.1.3.2 steps to reproduce in https://bugs.kde.org/show_bug.cgi?id=252026#c6 are still valid I get kioexec update dialog only for file, which was open first somehow libreoffice does not open files at all when connected via smb:// protocol (all other formats work OK) Ferdinand Gassauer , which smb related packages have you installed?
dpkg --get-selections *smb* libsmbclient:amd64 install libsmbclient-raw0:amd64 install python-smbc install smb4k install smbclient install smbnetfs install
This is also happening for me in Debian Jessie 8.3 Xfce desktop when I use Konqueror to find a GnuCash file on a NAS in my LAN and open it by right clicking on the filename in Konqueror. These files are in the .gnucash compressed XML format. All of the GnuCash 2.6.11 (from the Debian Jessie backport package) intermediate automatic backups and backups triggered by manual saves get written to /var/tmp/kdecache-username/krun/ with a prefix to the filename that appears to associate the file to a process number and a user name. They stay there after the GnuCash program is closed. When GnuCash is closed the user is asked whether to write the data back to the network source with the original filename, thus overwriting the source file. The net result is that there are no Gnucash backups at all on the network drive. If GnuCash is opened in a Gnome desktop on the same Debian Jessie machine all of the GnuCash intermediate backups get written back to the network source with the same filenames as when a local source file is opened. GnuCash pauses and waits while the files are written as it does with local files on either Ubuntu, Debian Gnome or Windows machines. I think that GnuCash actually renames the original source data file to create the backup file before writing the new data file.
KIO should automatically upload files if they change in cache. Would make KIO much more usable. Currently it's more like a Filezilla with more features - good for viewing or moving stuff, but really bad for editing. I am forced to use GVFS that allows everything I need.
Git commit a7758fb66481f05d1791687b415331a4f4af782f by Elvis Angelaccio. Committed on 15/04/2017 at 15:25. Pushed by elvisangelaccio into branch 'master'. kioexec: delegate upload to a kded module Introduce a kded module that kioexec can use to watch the cached files for changes. This allows kioexec to be fully functional even with applications that fork on startup, like libreoffice. If the kded module is up and running, kioexec tells it (via dbus) which file should be watched for changes and where to upload it when it is actually changed. All the files watched by the module are deleted when the module is destroyed. As a bonus side effect, the dialog that asks if changes should be uploaded is now displayed every time the user saves the file. If dbus is not available or the kded module is otherwise disabled, then kioexec falls back on the old behavior. Related: bug 370532 FIXED-IN: 5.34 Differential Revision: D5030 M +27 -1 src/kioexec/CMakeLists.txt A +111 -0 src/kioexec/kioexecd.cpp [License: LGPL (v2/3+eV)] A +53 -0 src/kioexec/kioexecd.h [License: LGPL (v2/3+eV)] A +11 -0 src/kioexec/kioexecd.json M +10 -3 src/kioexec/main.cpp M +1 -0 src/kioexec/main.h A +3 -0 src/kioexec/org.kde.kioexecd.service.in https://commits.kde.org/kio/a7758fb66481f05d1791687b415331a4f4af782f