Version: 3.3.1 (using KDE 4.3.1) Compiler: gcc 4.4.1 ? OS: Linux Installed from: openSUSE RPMs when saving files using an sftp url, the file attributes will be reset. Example how to retest this: nicht gefunden ivr@schulz:~/.hfn> touch /tmp/otto ivr@schulz:~/.hfn> ls -l /tmp/otto -rw-r--r-- 1 ivr users 0 4. Dez 15:52 /tmp/otto ivr@schulz:~/.hfn> chmod a+x /tmp/otto ivr@schulz:~/.hfn> ls -l /tmp/otto -rwxr-xr-x 1 ivr users 0 4. Dez 15:52 /tmp/otto ivr@schulz:~/.hfn> kate sftp://localhost/tmp/otto QThreadStorage: Thread 0x609940 exited after QThreadStorage 2147483636 destroyed ivr@schulz:~/.hfn> ls -l /tmp/otto -rw-r--r-- 1 ivr users 0 4. Dez 15:53 /tmp/otto ivr@schulz:~/.hfn> I did nothing on the file otto, only pressed "Ctrl-S" to save. (Which is another Bug -- since kate should not write an unchanged file!)
> (Which is another Bug -- since kate should not write an unchanged file!) Not necessarily, since the file may have been changed or deleted on disk. (With a local file you are usually notified of this, but with a remote file you may not be.) Anyway, I was just noticing this as well (in yesterday's trunk), though I'd suspect the bug really lies in KIO (maybe even libssh?) and not kate.
*** Bug 218099 has been marked as a duplicate of this bug. ***
I also am experiencing this on Opensuse 11.2 (KDE 4.3.5, Kate 3.3.5). Are there any workarounds? I found the local temporary copy kate saves and it has permissions of 600. The original files have 666 but once saved they become 644. Changing the permissions on the temp file has no effect.
Still present in Version 3.5.69, and still very annoying, basically makes it impossible to collaborate with others in the same remote dir. I could probably work around this with some acl-magic, but thats even more annoying. How does the mechanism work? Is the file created locally on saving and then transferred to remote using sth. like kfm-client? If yes, is is possible to maybe set a umask to get a more writeable temp-file, and have permissions preserved when its being copied to remote? Where in the architecture can this bug be fixed?
A quick check revealed the following information: The SFTP protocol is implemented in kdebase-runtime/kioslave/sftp/kio_sftp.cpp. If you go into function void sftpProtocol::open(...), there is a line as follows (at least in my KDE 4.4.5 sources): mOpenFile = sftp_open(mSftp, path_c.constData(), flags, 0644); This is the moment, where the existing file is replaced with the uploaded data in a new file (same filename though) and reset permissions. The KDE coding wizards should have a word here, too, but my suggestion would be to check the attributes (including permissions) if the file already exists and use the retrieved bit mask instead of just 0644.
Very bad! This makes Kate useless for me. Is there any solution? Thomas Fischer's suggestion sounds good.
Anyway, this is a kio issue.
*** Bug 336819 has been marked as a duplicate of this bug. ***
Well, we actually only set permissions if the application tells us to create the file! So why is the editor setting O_CREAT. The code looks like this: if (flags & O_CREAT) { mOpenFile = sftp_open(mSftp, path_c.constData(), flags, 0644); } else { mOpenFile = sftp_open(mSftp, path_c.constData(), flags, 0); } You have to understand that if I add code to first check if the file exists and we overwrite a file and should reuse the permission. I have a additional roundtrip for each file, which significantly slows down copying a lot of files.
This looks more like an old kate bug.