Community
Participate
Working Groups
Build GM5 Linux only If you try to delete a read-only project from the filesystem, an error dialog opens saying that the delete failed. 1) Create a simple project, called Foo 2) Mark Foo as read-only 3) Select Foo in the navigator and invoke Edit->Delete - This prompts whether to delete the project from the filesystem 4) Select the radio butto for deleting the contents on disk - another dialog opens warning that the resource is read-only, asking you to confirm the delete 5) Click on the Yes button - The Delete problems error dialog opens with the message "Problems encountered while deleting resource" - Under details it simply says "Could not delete /Foo" Since the user has been prompted that the resource is read-only, the delete should not fail.
*** Bug 22910 has been marked as a duplicate of this bug. ***
Broken on Windows in build 20020827 as well.
Deleting read-only projects with or without read-only contents works on Windows with build 20021018. Deleting non-empty read-only folders in Linux does not work in general. Even in a shell you get an error message. Entered Core bug 25220 to see if Core can work around this. In any case UI should not do anything special on Linux
In build 20030206 deleting a project does not work on Windows if it contains read-only files. It does work when only the project itself is marked read-only on the file system. This is consistent with the move/delete behavior discussed in bug 29669. UI should not attempt to make read-only files read/write in order to delete them. Still should consider if deleting a read-only project should work on Linux.
Reassigning to Nick since he is taking ownership of Navigator
Still exists in eclipse-SDK-3.0M7-win32.zip
Also: if you mark a folder r/o and then try to delete a child resource it fails as well despite the child being r/w.
Looks like a duplicate of bug 25220, which is fixed. I'll test it when I get a chance.
Just verified this bug on 3.1 M7 and it still fails. I believe the core behaviour is correct, as it is exactly the behaviour one gets from a Unix shell. I think we should respect the platform behaviour here rather than make it act like Windows. Having said that, it's clearly wrong that the UI prompts the user if it's ok to delete the read only resource, and then fails to delete. I think after prompting the user if it's ok to delete the read only resource, the UI should clear the read-only bit. In Kim's case, where the parent folder is read-only, and you try to delete the child, the behaviour seems ok. The user is not prompted if they want to delete the resource despite it being read-only. Both creation and deletion of resources under a read-only parent folder fails on Linux, which obeys the Unix permission semantics. In any case, this bug isn't important enough to consider for 3.1.
*** Bug 65893 has been marked as a duplicate of this bug. ***
Since we can't control whether or not it's possible to delete the resource in any particular platform + filesystem, we should change the dialog text from "Do you still wish to delete it?" to "Would you like to attempt to delete it anyway?". Flagging this (message change) for 3.4
Bah. Message change did not get fixed for 3.4.
> Bah. Message change did not get fixed for 3.4. How about fixing it now (before the NLS freeze)? In 3.6, the checkbox suggested in bug 65893 comment 10 could be added when bug 254444 got fixed.
Removing 3.5 target milestone. We are in the end-game now. Please have a look and decide if this should be targeted at 3.6.
Bug 297228 has extended the set of supported native file attributes (new EFS.* attributes). With those, it should become possible to delete files in the UI no matter whether they are "locked" or "read-only".
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
