https://bugs.kde.org/show_bug.cgi?id=345687
Harald Sitter <sit...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REPORTED |RESOLVED
Resolution|--- |NOT A BUG
CC| |sit...@kde.org
--- Comment #3 from Harald Sitter <sit...@kde.org> ---
What Andreas proposed wouldn't actually change anything. The open() isn't the
problem. The process umask does apply when creating a file. The problem is the
chmod() when the transfer is complete because chmod is not subject to umasking
(otherwise you couldn't ever set more liberal permissions than the umask
allows).
The trouble is that we must chmod from an API POV. Permissions are either
present or not, and when they are present they ought to be applied unless the
file already exists on the remote.
https://api.kde.org/frameworks/kio/html/classKIO_1_1CopyJob.html#a3bd4dda22a3bd50adf195542d9d009ad
https://api.kde.org/frameworks/kio/html/classKIO_1_1SlaveBase.html#a1f382438285d8f1112e9340f3c0e8bbf
When the client (e.g. dolphin) sets setDefaultPermissions=true the current code
would behave exactly as expected and documented. But since the client does not,
we ought to obey the API expectation that the permissions given to the sftp
slave will be fully applied to the resulting file, hence the chmod. This is
also in line with how this works for ftp (which is slightly more core than
sftp).
All that said, currently this is not a bug. This may change per bug #418499
--
You are receiving this mail because:
You are watching all bug changes.
