Community
Participate
Working Groups
- On Windows local, create file a.txt - Launch a shell and execute "attrib +r a.txt" - In RSE, select a.txt and choose delete --> Since the file is read-only, a confirmation dialog should ask the user "(a.txt) is read-only. Do you really want to delete it?" --> In case a multi-selection was scheduled to delete, when hitting the first read-only file or directory the dialog should come up and offer options [yes] [no] [yes for all] [no for all] [cancel] -----------Enter bugs above this line----------- RSE 1.0.1 Release Test installation : eclipse-SDK-3.2.1 RSE install : Download RSE-SDK-N20061215-0100 java.runtime : Sun 1.5.0_09-b03 os.name: : Windows XP 5.1, Service Pack 1 ------------------------------------------------ systemtype : Windows-local, Dstore-win, Dstore-linux targetos : Red Hat Enterprise Linux WS release 4 (Nahant Update 3) targetuname : Linux parser 2.6.9-34.EL #1 i686 athlon i386 GNU/Linux targetvm : Sun Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode) ------------------------------------------------
In case we support extended file attributes like "system" and "hidden", such attributes should also trigger the confirmation dialog
Kevin I think you've been dealing with similar things before, could you take a look?
The current behavior for deleting file trees which include read-only files differs between connection types: - dstore and local give up as soon as one read-only file is found - ftp does not support recursive delete at all (but bug 196351 asks for recursive delete of folders in FTP) - ssh does delete read-only files too through rm -rf command (but bug 155189 asks for a progress for this) We decided in http://wiki.eclipse.org/DSDP/TM/Committer_Phone_Meeting_21-Aug-2007 that the correct behavior is to do the same as EFS does: * recursively descend and delete what we can delete * accumulate errors due to read-only files in a MultiStatus * when done, present the errors due to the MultiStatus to the user, allowing to select a list of files/directories for setting writable so they can be deleted in a second run. The required changes for this seem to be too large for 2.0.1 -> assigning to Future Note that a workaround for recursive delete on any type of connection is to use EFS: Share a parent of the remote folder in the workspace through EFS, then delete the child as needed. Note though, that EFS will lead to a lot of overhead due to requesting directory info and refreshing.
We might also add API to "force" deletion of read-only files right on the server in the future. This would make sense because when the user knows he wants to "force" deletion right away, it could be handled much more efficiently right in the server (e.g. through SSH rm -rf).
