Version: 4.5.8 (using 3.5.8, Debian Package 4:3.5.8.dfsg.1-7 (lenny/sid)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.23.15 I can open text files from sshfs mounted directories but I cannot save them. My workaround is to use the fish protocol. But I prefer sshfs because it runs much more stable.
Sorry, I forgot to write, that an error message about bad file permissions appears. I assume they are related to the file owner ID. I have a different ID on my notebook than on the file server and I cannot change that situation. After that error message, kwrite lets the original text file unchanged and stores another file with the ending ".part" with the new content. Obviously, sshfs cannot rename+overwrite a file in one step. Example: old file: test.txt temp file: test.txt.part kwrite tries: rename test.txt.part test.txt Maybe the solution is to delete the old file before renaming the temp file.
If katepart deletes the file all the permissions are gone. Imo, this is not really a kate bug. maybe a permissions problem not even related to kde, of if you are using a kio-slave, then it's maybe a kioslave issue.
> ... all the permissions are gone. This part is probably wrong, as the .part-file is moved then. Not kwrite tries to rename, but kio.
If a problem, then kio
The problem has been resolved partially. Kwrite can now overwrite existing files on sshfs mounted directories using the menu command Save-As. But It refises to overwrite files using the Save command, then it says: YOu don't have permission to overwrite the file. This is not true, I have that permission. The problem might be related to the owner ID of that file, which does not exist on my local machine. But the group ID exists and has rw permission.
I failed to reproduce the reported problem using KDE SC 4.8 RC1. Is this still a problem for the reporter in recent versions?
I cannot reproduce the problem anymore with Debian stable, package version of kwrite is 4:4.4.5-2. It works fine now.
Unfortunately, it seems this bug is back in KDE 4.10. I use Arch Linux and I did a system upgrade which upgraded KDE packages from 4.9.5 to 4.10.0. Trying to overwrite a file in mounted sshfs filesystem in Kate, I get an error: "The document could not be saved as it was not possible to write to [file_name] Check that you have write access to this file or that enough disk space is available." I can create new files, though - the problem, as in original description, appears only on overwriting. I tried remounting with "-o idmap=user", which translates permissions to use my UID, but it didn't help. The only fix was to downgrade the packages back to 4.9.5.
Created attachment 77190 [details] Strace log for overwriting a file in KDE 4.10
Is this issue only reproducible with Kate?
I only tried Kate and KDevelop (which uses internally Kate components). I think it is specific to the way Kate writes files, writing first to temporary file and then renaming it. I've found a better workaround: mounting sshfs with "-o workaround=rename". There seems to be a problem with rename() system call, which normally doesn't work for sshfs, but is patched somehow with this workaround option. But it has its own disadvantages (e.g. files saved with this option change permissions to include exec rights: 775). Looking at strace from 3.9.5, I see that previously a file was simply saved in place, not via a temporary file. I think there should be a sort of fallback mechanism on this older method, if renaming the temporary file doesn't work. Or there could be a configuration option to choose the desired behavior. Either way, IMO relying on rename() to work in all cases is a bad choice ("man 2 rename" lists more scenarios where it could fail).
That's not specific to kate, it's the KSaveFile/QSaveFile approach, which is the only way to ensure that files don't get corrupted when the partition is full, or the app crashes while writing out the file. rename() has to work (and has to be able to replace existing files), that's the expected POSIX behavior of rename(). Why doesn't this work for sshfs? Sounds like a sshfs bug to me.
After looking through several forums and mail lists, I found this thread: http://www.mail-archive.com/macfuse-devel@googlegroups.com/msg00557.html It seems that rename() is supported by sftp protocol, but it has different semantics than the POSIX version: if renaming to existing file, it will fail with EPERM. Sshfs with "-o workaround=rename" works around this by using temporary files and unlinking the existing file. This temporary file is created with those wrong permisssions, but I think I can live with that. Well, in that case, I withdraw my comments: it is not a bug in KDE. Thanks for your time anyway.
> I've found a better workaround: mounting sshfs with "-o workaround=rename". > There seems to be a problem with rename() system call, which normally > doesn't work for sshfs, but is patched somehow with this workaround option. > But it has its own disadvantages (e.g. files saved with this option change > permissions to include exec rights: 775). As a workaround for the exec rights disadvantage one can use the noxec option: "sshfs -o workaround=rename -o noexec"