Community
Participate
Working Groups
If you make a file read only it's not possible to Delete/Rename/Move that file. In 2.0.0.1 you can rename/delete/move a read-only file. Steps to Reproduce: 1. Right click on a file and select Properties. 2. Check Read-Only. 3. Click Okay. 4. Right click on the file. --> Delete/Rename are disabled. Move isn't even shown. -----------Enter bugs above this line----------- TM 2.0.1 Testing installation : eclipse-SDK-3.3 RSE install : Dev Driver - July 25th, 2007 java.runtime : Sun 1.5.0_11-b03 os.name: : Windows XP, Service Pack 2 ------------------------------------------------
Hm... What do you think would be expected behavior? On Windows commandline, read-only files can be renamed but not deleted or moved: Y:\>touch x Y:\>attrib +r x Y:\>ren x y Y:\>del y Y:\y Access is denied. On UNIX, read-only files can be deleted, renamed or moved but only if the container (parent directory) is writable: 504 mober@parser~/RSETest>touch x 505 mober@parser~/RSETest>chmod ugo-w . 506 mober@parser~/RSETest>rm x rm: cannot remove `x': Permission denied 507 mober@parser~/RSETest>mv x y `x' -> `y' mv: cannot move `x' to `y': Permission denied So, I see the following options: a) Add API methods on IRemoteFileSubSystem#canDelete() / canRename() --> Then each subsystem can do its own checks depending on whether the remote is Windows / UNIX or whatever. b) Always allow delete/rename/move in the UI but catch the exception (and display to the user) when it fails. c) Like (b) but with an extra dialog like "file xyz is read-only. Are you sure you want to (delete, rename, move) it?" I think that anything else would be a wild guess as to how we think a remote host operates, and we'd either deny too many operations or allow too many. What do you think? The other thing I'm really curious about is how and why this regression could be introduced. That alone is worth investigating the code.
Bug 168219 requests asking for confirmation when deleting read-only files. Bug 191548 is about problems when trying to move read-only folders.
This regression was introduced by bug 187130, with the changes made in SystemViewRemoteFileAdapter. I tried the following delete case's using 2.0.0.1 on local-windows, ftp, ssh, and linux dstore: File is not read-only and parent folder is read-only. File is read-only and parent folder is not read-only. File is read-only and parent folder is read-only. Directory is read-only, parent directory is not read-only Directory is read-only, parent directory is read-only Local-Windows worked in all cases. FTP: File is not read-only and parent folder is read-only. --> Error Permission Denied. File is read-only and parent folder is not read-only. --> Delete works fine. File is read-only and parent folder is read-only. --> Get an error message saying you don't have permission Directory is read-only, parent directory is not read-only --> Can't delete directory if it contains files. Get Error saying not empty. --> If doesn't contain files then delete is allowed. Directory is read-only, parent directory is read-only --> Get an error SSH: File is not read-only and parent folder is read-only. --> Error Permission Denied. File is read-only and parent folder is not read-only. --> Delete works fine. File is read-only and parent folder is read-only. --> Error Permission Denied Directory is read-only, parent directory is not read-only --> Directory is removed from Remote Systems View, but doing a refresh and it is back. Directory is read-only, parent directory is read-only --> Error Permission Denied DStore - Linux: File is not read-only and parent folder is read-only. --> Error Permission Denied. File is read-only and parent folder is not read-only. --> Delete works fine. File is read-only and parent folder is read-only. --> Error permission denied. Directory is read-only, parent directory is not read-only --> Directory is removed from Remote Systems View, but doing a refresh and it is back. Directory is read-only, parent directory is read-only --> Directory is removed from Remote Systems View, but doing a refresh and it is back. I tested the same scenario's with rename and everything either worked or displayed an error. Interestingly all case's on dstore - linux were not allowed. This is why I wasn't sure why these actions were disabled as they were displaying an error in most case's except delete a directory that is read-only. I think we should do option c though and let the user decide what to do if a file is read-only, but as you mentioned on unix machines if the parent is read-only then we can't delete/rename. Do we change the parent to be not read-only, do the delete and change it back or let it error on the user still?
Created attachment 78440 [details] Removes canWrite checks After thinking about this more and bug #187130 I don't think any actions should be disabled on read-only folders because what can and can't be done depends on the system type. If we want to disable certain actions on read-only folders we will need to do it based on the system type. Only exception is Paste which was disabled before and should remain disabled because we don't want to do a transfer of resources to the workspace only to find out they can't be transfered to the remote, when doing copy/paste across connections. Attached patch simply removes the canWrite checks for those actions. Legal Message: I, Kevin Doyle, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer, IBM Canada Ltd. to make this contribution under the EPL.
I'm surprised that with your patch, you allow pasteClipboardAction newFolderAction newFileAction even on read-only elements. My intuition would tell me that these should not be available on read-only elements. Is there a reason for this, other than just restoring 2.0 behavior?
For Windows/Local-Windows you can create new files/folders in read-only folders. That is why I re-enabled New File/Folder. Paste is not enabled on read-only folders, but it shows up as disabled now.
Ok - since it is a regression, I'm much in favor of allowing this into 2.0.1 DaveM - want to also have a look and commit it, or should I just go for it?
Kevin and I discussed this earlier and I agree. If you'd like to commit, that's fine.
Patch applied. Thanks!
Verified fixed in I20071108.
