Version: 3.4.2 (using KDE 3.4.2, compiled sources) Compiler: gcc version 3.3.4 OS: Linux (i686) release 2.6.10 Assume the ~/works directory to be readwrite (rwx) and the ~/works/readonly directory to be readonly (r-x). Logged in as a non-root user a "touch works/touch01" will succeed and a "touch works/readonly/touch02" will fail (screenshot 01). A (drag and) drop on ~/works is allowed (a move/copy/link context menu is shown - screenshot 02) and succeeds. A (drag and) drop on ~/works/readonly is also allowed (the same move/copy/link context menu is shown) and fails (screenshot 03). A (copy and) rightclick on ~/works gives a context menu with a "paste" option (screenshot 04) and the paste succeeds. A (copy and) rightclick on ~/works/readonly gives a context menu without a "paste" option (screenshot 05). Logged in as root both a "touch works/touch01" a "touch works/readonly/touch02" will succeed (screenshot 06). A (drag and) drop on both ~/works and ~/works/readonly is allowed (a move/copy/link context menu is shown) and succeeds. A (copy and) rightclick on ~/works gives a context menu with a "paste" option and the paste succeeds. A (copy and) rightclick on ~/works/readonly gives a context menu without a "paste" option - note that if a "paste" option were given the paste would succeed. Sensing whether a (copy and) paste is likely to succeed seems like a nice thing to do. Alas the decision for root for ~/works/readonly is downright wrong. Also, sensing whether e.g. Computer Associates eTrust Access Control and/or the OS Access Control Lists are present and make ~/works readonly at a higher level than (rwx) does not seem very practical to me - let alone any other higher level methods that exist / may exist in the future. Therefore the approach as taken for (drag and) drop to provide the gesture in the context menu and let the system decide on whether to succeed or fail seems more appropriate to me. It should be noted that in KDE 3.2.3 a (copy and) rightclick on ~/works/readonly indeed gave a context menu with a "paste" option (screenshot 07) and that the paste failed for the non-root user (screenshot 08) and succeeded for root.
Created attachment 12129 [details] screenshot 01 - touch for non-root
Created attachment 12130 [details] screenshot 02 - (drag and) drop context menu
Created attachment 12131 [details] screenshot 03 - (drag and) drop failure
Created attachment 12132 [details] screenshot 04 - (copy and) rightclick context menu with paste option
Created attachment 12133 [details] screenshot 05 - (copy and) rightclick context mentu without paste option
Created attachment 12134 [details] screenshot 06 - touch for root
Created attachment 12135 [details] screenshot 07 - (copy and) rightclick context menu in KDE 3.2.3
Created attachment 12136 [details] screenshot 08 - (copy and) paste failure in KDE 3.2.3
I found a SLAX CD witht Kde 3.4.0 - the symptom is already present there.
Created attachment 12179 [details] screenshot 09 - (drag and) drop icon view
Today I tested with the Klax 3.5 alpha 1 CD - boot "klax nogui", logon as root/toor and issue "startx". In addition to what I already reported I saw that a (drag and) drop on ~/works/readonly is allowed (move/copy/link context menu) only in tree view, in icon view one gets a "You cannot drop any items in a directory in which you do not have write permission" message in the status line (screenshot 09). I verified that the same applies to KDE 3.4.2.
As this bug got rather long here is a summary: A (copy and) paste into a readonly directory is not possible as the rightclick menu has no paste option. If it had, the paste would succeed for root. A (drag and) drop into a readonly directory in icon view is not possible as a status line message instead of a move/copy/link context menu is given. If the context menu would be given, the drop would succeed for root. Please enable these features for root, or alternatively for everyone do not test for the directory permissions and let the system decide.
I opened bug 110587 for KDE 3.5 (alpha1)
I retested with KDE 3.5 - the problem is still there ... Actually this bug is not even confirmed :((
I retested with KDE 3.5.1 compiled from sources - the problem is still there ... Actually this bug is not even confirmed :((
KDE 3.5.2 compiled from sources - the problem is still there ...
KDE 3.5.3 compiled from sources - the problem is still there ...
Confirmed in 3.5 branch r575787. Oddly, "Paste file" appears in the Edit menu when viewing a readonly directory, though it doesn't appear in the context menu.
Dear Philip, Fill the copy "buffer" by rightclicking on a file and choosing "copy" from the context menu. Then switch to the readonly directory. Indeed the "edit" menu now shows a "paste" option. Choose that paste. When done as root the paste is successful (correct), when done as non-root it fails (access denied, correct). Also oddly, on the "edit" menu for a readonly directory the "create new" option is enabled. Create e.g. a new file. When done as root this is successful (correct), when done as non-root it fails (access denied, correct). Kind regards, Dick
Hrm, on second look this might not be a bug, but intended behaviour. I'd have to leave the developers to comment
Kde 3.5.5 compiled from sources - no change ...
I can confirm this and it is surely not intended that you are unable to paste things via the context menu but able to do so via drang and drop, if you are root and the directory is r-x. the paste entry should be enabled all the time when running konqueror with root priviliges.
With KDE 3.5.6 no change. With KDE 3.5.7 no change. With KDE 3.5.8 no change.
It seems fixed on 3.5.9 but I'm not 100% to have understand the bug: I've created a directory where the user cannot write in. From konqueror the DnD action and the context menu doesn't have the "paste" action. Instead it is still present in the main menu of konqueror. On konqueror 4 this has not been fixed, but konqueror 4 use Dolphin. I'll open a bug report for dolphin.
Message from the Bugsquad and Konqueror teams: This bug is closed as outdated, as we do not have the manpower to maintain the KDE3 version anymore. If you still can reproduce this issue with Konqueror 4.8.4 or later, please open a new report. Thank you for your understanding.