See steps to reproduce Reproducible: Always Steps to Reproduce: 1. Make any file e.g. /tmp/test 2. Right click it -> Properties -> Permissions tab -> Advanced permissions 3. Add a named user entry, deny its right to e.g. read the file 4. OK, OK to close the dialogs 5. Repeat step 2 6. See the entry missing 7. Restart dolphin 8. The entry is visible Actual Results: The newly created entry is missing from the Advanced permissions list Expected Results: The entry should be updated after modification
*** Bug 155018 has been marked as a duplicate of this bug. ***
*** Bug 173690 has been marked as a duplicate of this bug. ***
Restarting Dolphin is not required to reproduce 8, you simply have to refresh the view using F5. Not sure if the caching is wrong inside Dolphin or kio.
In fact, I've noticed Dolphin sometimes not updating directory contents when displaying it, and sometimes even just having it in "go back" history when returning to the directory. Maybe this is related. I don't have strict steps to reproduce, can try finding some if needed.
Still present in KDE 4.13.2 from kubuntu-backports PPA.
Still an issue in KDE Frameworks 5.45.
Still an issue in KDE Frameworks 5.70.0
(In reply to Danil Shein from comment #7) > Still an issue in KDE Frameworks 5.70.0 One suggestion about root cause from my experience with KPropertiesDialog source code: As far as I cold understand KPropertiesDialog receives KFileItem or KFileItemList instance as input. All ACLs related data is stored in and managed through related KFileItem UDSEntry. It looks like when you've reopen file properties dialog again after ACL changes applied it is receive an KFileItem without appropriate UDSEntry and displays ACL as inherited from regular UNIX permissions. Can't say where and why it actually happens. My suggestion is based on experience playing around with code: path = "/home/dshein/src/tmp/1/2/share/1.txt"; KFileItem kfitem(QUrl::fromLocalFile(path)); KPropertiesDialog kpd(QString("File properties"), 0); kpd.showDialog(kfitem, 0); kpd.showDialog(QUrl::fromLocalFile(path), 0); kpd.showDialog(kfitem, 0); kpd.showDialog(QUrl::fromLocalFile(path), 0);
(In reply to Danil Shein from comment #7) > Still an issue in KDE Frameworks 5.70.0 One suggestion about root cause from my experience with KPropertiesDialog source code: As far as I cold understand KPropertiesDialog receives KFileItem or KFileItemList instance as input. All ACLs related data is stored in and managed through related KFileItem UDSEntry. It looks like when you've reopen file properties dialog again after ACL changes applied it is receive an KFileItem without appropriate UDSEntry and displays ACL as inherited from regular UNIX permissions. Can't say where and why it actually happens. My suggestion is based on experience playing around with code: path = "/home/test/1.txt"; // file with ACL KFileItem kfitem(QUrl::fromLocalFile(path)); KPropertiesDialog kpd(QString("File properties"), 0); kpd.showDialog(kfitem, 0); // always display ACLs inherited from regular permissions (incorrect) kpd.showDialog(QUrl::fromLocalFile(path), 0); // always display consistent file ACls auto job = KIO::stat(url); job->exec(); KIO::UDSEntry entry = job->statResult(); kfitem = KFileItem(entry, url); kpd.showDialog(kfitem, 0); // display consistent file ACls
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/581
Git commit 74d6983294f58d75ce776fd9011a3d3355b37f57 by Ahmad Samir. Committed on 14/09/2021 at 23:31. Pushed by ahmadsamir into branch 'master'. KFileItem: refresh() shouldn't discard ACL attributes Following the code: - changing the ACL permissions of a file via KPropertiesDialog - when the dialog is closed the dirlister which is installed on the view (in e.g. Dolphin or the open file dialog) is notified that the item has changed - KCoreDirLister would then call item.refresh(), if the old item had the ACL field(s) set, and they would be gone after calling refresh() FIXED-IN: 5.87 M +0 -4 src/aclhelpers_p.h M +22 -0 src/core/kfileitem.cpp https://invent.kde.org/frameworks/kio/commit/74d6983294f58d75ce776fd9011a3d3355b37f57
This bug is still reproducible on neon unstable. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.23.80 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.3 Graphics Platform: Wayland
it's still reproducible on Arch Linux after update to frameworks 5.87 and reboot. Operating System: Arch Linux KDE Plasma Version: 5.22.90 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Graphics Platform: Wayland