The check box "Only owner can rename and delete folder content" does not set a directory's "sticky bit". If the directory's "sticky bit" is set from the CLI, Dolphin indicates the "T" in the "Permissions" field and, if the check box status is not changed, does not change the directory's "sticky bit". If however the check box is cleared, or cleared and then re-enabled, on clicking the "OK" button, the directory's "sticky bit" is cleared. Reproducible: Always Steps to Reproduce: 1. Choose a directory which does not have the "sticky bit" set. 2. Open a directory's Properties. 3. Select the "Permissions" tab. 4. Enable the "Only owner can rename and delete folder content" check box. Actual Results: The directory's "sticky bit" is not set. Expected Results: The directory's "sticky bit" is set. Given that a directory's "sticky bit" is a basic, fundamental, standard Linux and UNIX® directory file property, it is possibly quite embarrassing that this has somehow been overlooked.
Thanks for the bug report! Can you please tell us your KDE frameworks version? Looks similar to bug 365795.
openSUSE Leap 42.1 package naming: ------------------------------------------------------ Name: plasma-framework Summary: Plasma library and runtime components based upon KF5 and Qt5 Repository: openSUSE-Leap-42.1-Update Version: 5.21.0-15.1 rpm -q: plasma-framework-5.21.0-15.1.x86_64 ------------------------------------------------------ Name: plasma-framework-components Summary: Plasma QML and runtime components based upon KF5 and Qt5 Repository: openSUSE-Leap-42.1-Update Version: 5.21.0-15.1 rpm -q: plasma-framework-components-5.21.0-15.1.x86_64 ------------------------------------------------------ KDE-Infocentre: Version 5.5.5 Under: - KDE Frameworks 5.21.0 - Qt 5.5.1 (compiled against 5.5.1) - The xcb Window system CPU: AMD A10-5750M APU with Radeon(tm) HD Graphics Memory: 6.9 GB
Also noted in the openSUSE Bugzilla as Bug 991010: <https://bugzilla.opensuse.org/show_bug.cgi?id=991010>
And also openSUSE Bug 978935: <https://bugzilla.opensuse.org/show_bug.cgi?id=978935>
And also openSUSE Leap 42.2 Bug 993941: <https://bugzilla.suse.com/show_bug.cgi?id=993941>
Bug, certainly... but this is mentioned in both Leap 42.2 and 42.3 Release Notes: https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/42.2/ 3.2 Dolphin Does Not Set Extended Permission Bits The version of the KDE file manager Dolphin that is shipped with openSUSE Leap 42.2 cannot set “Extended Permission” bits (GID, “Sticky”). Additionally, closing the Dolphin permissions dialog by clicking OK clears existing extended permissions bits. To avoid such issues, edit permissions with Konqueror (GUI) or chmod (command line) only. https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/42.3/ 3.2 Dolphin and Konqueror Cannot Set Extended Permission Bits The versions of the KDE file managers Dolphin and Konqueror that are shipped with openSUSE Leap 42.3 cannot set “Extended Permission” bits (GID, “Sticky”). Additionally, closing the Dolphin permissions dialog by clicking OK clears existing extended permissions bits. To avoid such issues, edit permissions with chmod (command line) only.
Commandline would work for me, but this is not feasible in a company. Going to try nautilus and eiciel.
The KPropertiesDialog is provided by KIO, re-assigning.
Marking as duplicate of since the entire extended permission thing is broken. *** This bug has been marked as a duplicate of bug 365795 ***