https://bugs.kde.org/show_bug.cgi?id=418499
Bug ID: 418499
Summary: API clarification SlaveBase::Copy permissions & umask
for remote slaves
Product: frameworks-kio
Version: git master
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: fa...@kde.org
Reporter: sit...@kde.org
CC: kdelibs-b...@kde.org
Target Milestone: ---
See https://bugs.kde.org/show_bug.cgi?id=345687
TLDR: we ignore server-side umasks because we get explicit permission bits in
Slave::copy and explicitly set them via chmod (thus ignoring the umask). The
documentation doesn't explicitly say the permissions are explicit but it is
certainly implied and it is how (e.g.) the FTP slave works too.
https://api.kde.org/frameworks/kio/html/classKIO_1_1CopyJob.html#a3bd4dda22a3bd50adf195542d9d009ad
https://api.kde.org/frameworks/kio/html/classKIO_1_1SlaveBase.html#a1f382438285d8f1112e9340f3c0e8bbf
I would make an argument that KIO::CopyJob has this somewhat backwards. I would
rather expect copies across protocol and/or host boundary to only have implicit
default permissions (e.g. 644) but be subject to umasking (i.e. stay away from
chmod).
Simply put:
- copy within same protocol and host: use input permissions
- copy across protocol or host: use default permissions potentially subject to
umask (e.g. avoid chmodding) and ignore the input permissions
To accomplish that we'd kind of only need to send -1 when
src.scheme!=dst.scheme || src.host!=dst.host.
Mind you I'm equally content with keeping everything as-is even though on paper
I find the behavior underwhelming.
--
You are receiving this mail because:
You are watching all bug changes.
