Community
Participate
Working Groups
For Linux, Unix, and zFS (HFS) file systems, there are permission bits that dictate read / write / execute permissions. There is no way to manipulate these bits (with the exception of going to the shell interface and issuing chmod.) One suggestion is to place the current permission settings in the properties view, and allow the permissions to be altered (within the current constraints of the current user's allowable capabilites). Side question on the same topic - what happens when you copy/paste a directory (sub)tree from one location to another? Are the permission bits carried forward to the newly created foldering structure? IMHO, the permission bits should be inherited.
Some random thoughts on this: * The disadvantage of a Property page is that it allows viewing / editing file permissions for one file at a time only. At least in my experience, I often want to do a bulk change of file permissions. Context menu actions and a tabular display of the properties (e.g. in the Remote Systems Details View) seem to be more appropriate for this. * Exact representation of file permissions differs vastly between different system types. There is the UNIX-style rwx format; Windows-style read-only bit; WinNT-style ACL's; Linux-style ACL's; and many more. Reflecting all of these in an abstract framework seems not appropriate. So this leaves us with two basic choices: a) Go with the least common denominator, and support a plain "Read Only" flag only, like in the Eclipse Resource Navigator's Property Page. It's meaning on the remote system would always be "set the file read-only / writable for the current user, if possible". This option would probably work for 60% of the users, and it would be very simple to use. b) Leave the display as well as changing of file permissions up to the actual subsystem implementations. For instance, as settings in the file's Property sheet which could even be editable in there. This would allow for a much more exact representation of permission bits as allowed on the concrete remote system, but would typically not be as user-friendly. Option (a) would require API changes like IFileService.setReadOnly(boolean). The capabilities of the EFS implementation in IFileStore.putInfo() might serve as the template for what the additional API would need to support. Option (b) might work without API changes, but potentially force some code duplication among several different subsystems - and, more importantly, a FileServiceSubSystem that allows switching the IFileService beneath its toes would have a hard time getting and changing the information. I think that we might need to work on both options. (a) in order to support more (all?) features of EFS. (b) since it should be easy to show the native file permissions as a Property, and it will be helpful doing so. For modifying these properties, we might want a generic method of changing properties of the objects resented by any subsystem implementation, but I'm not so sure about this. Discussion opened - - what does the community think about the need for batch permission changes? - is a nice UI for the "read only for current user" flag sufficient? - for the more advanced settings, do we need a UI or is chmod sufficient?
PS: For Copying / Moving a directory tree, currently (RSE 1.0) * ssh SftpFileService does "cp -Rp" so it preserves permissions * dstore UniversalFileSystemMiner does "cp -r" on UNIX so it doesn't preserve does "xcopy /S /E /K /O /Q /H /I" on Windows so /K /O does preserve does plain "cp" or "copy" for single files so this doesn't preserve * local LocalFileService does "cp -r" on UNIX so it doesn't preserve does "xcopy /S /E /K /Q /H /I" on Windows so /K preserves some does plain "cp" or "copy" for single files so this doesn't preserve * for ftp RNFR/RNTO I'm not sure but I guess it keeps permissions * For copying across different hosts, - permission bits are always reset in the normal case - may be kept when "supertransfer" is enabled in Preferences:Files, so the tree is transferred as ZIP or TAR archive. This currently works for dstore only. I agree that the semantics should be unified. I'd be in favor of always keeping permissions for trees when possible, and never keeping permissions when copying individual files. Comments?
If possible, we should retain the permissions upon copying independent of copying a single file or a directory structure. When copying across systems, permissions should be honored especially when copying to/from like systems.
Having unix-like permissions displayed, imho, would make this much more usable, even if one could not edit the permissions (however, as soon as you display the permissions, someone would want the ability to alter them!) Having a bulk update is useful (as you mention). Perhaps engaging a UI designer to see if there is a reasonable approach is acceptable. Perhaps the 'bulk' change is a cascade action off a directory structure.
Created new bug 165891 for tracking the issue of preserving permissions during copy. For viewing and changing permissions, I'm proposing the following: * Each subsystem should be free to register Properties for displaying permissions in a way that's native to the subsystem. This does not need any API change and can (should) be implemented right away. * For changing permissions, each subsystem should be free to register an action for doing so in a system-dependent manner. RSE should come with two default actions that can be re-used: - One for Windows systems supporting only "isReadOnly" and "isArchive" - One for UNIXy systems ("Universal") supporting "rwxrwxrwx". These actions should show property sheets similar to what Windows Explorer is doing for showing/changing permissions on a multi-select: Given a multi-select in the RSE tree or table, the action should show a Property sheet with the Union of permission bits. For UNIX, checkboxes should be shown for the "rwxrwxrwx" bits, where - any bit that's on for ALL files is on - any bit that's on for SOME files but off for others should be gray - any bit that's off for ALL files should be off User can change the checkboxes. For those that have been changed, - "chmod +r" commands are created for any bit that's switched ON - "chmod -r" commands are created fro any bit that's switched OFF For actually performing the action of changing permissions on the remote system, a RemoteCommandShellOperation should be used in order to perform the required commands on a remote command line. I'm not in favor of adding API for these changes since the kinds of permission bits are just too different between various kinds of remote system. Having a shell command line seems to be the most appropriate common denominator between all of those. Please comment on this proposal.
*** Bug 166303 has been marked as a duplicate of this bug. ***
As bug 166303 and bug 166302 show, the "read only" attribute of a file has particular importance. Looks like it might be good to add API for set/getReadOnly to IFileService after all. We might need to implement more features that EFS already has.
This just popped up again in the context of FTP, since other clients like CuteFTP do expose the "permissions", "owner" "group" as Strings. Commons Net also provides the "raw listing" as String. As mentioned before, the problem with the approach in Comment #5 is that we duplicate code between the various file subsystems. As mentioned, the other approach is changing API to allow IHostFile expose permissions and ownership (or any generic property) via API. One other advantage of this is, that such Properties could go into the Properties View where it's expected (if each subsystem does it separately it would need to subclass RemoteFileAdapter for doing so). I also changed the summary (old value: "Request UI tools for showing / editing file permissions" For the special case of permissions, specific API might be desirable in order to allow changing them, while for the others it could be generic as well. I'm not sure if we should also provide API to modify those generic properties, this might be discussed in a separate bug.
Bug 209593 was opened to address permissions for files. There is currently support for reading SSH, FTP and Dstore permissions although the modify support is currently only available for DStore. Larry, in your use of USS, you will probably need to extend the miner to provide this support (if you're not picking up the open RSE one).
I think that this has essentially been fixed in 3.0M5 with bug 209593. For carrying forward permissions on copying between subsystems, EFS does preserve the permissions as far as it knows them; other subsystems do not, they may also silently ignore non-readable items when copying. So, two questions remain: (1) Preserve permissions on Copying, as per comment 2? (2) A "Unix-style" rwxrwxrwx property page is currently in place as UI. Dave do we have API to replace this with a subsystem-specific UI for more advanced / different kinds of permissions?
(In reply to comment #10) > I think that this has essentially been fixed in 3.0M5 with bug 209593. > For carrying forward permissions on copying between subsystems, EFS does > preserve the permissions as far as it knows them; other subsystems do not, they > may also silently ignore non-readable items when copying. > So, two questions remain: > (1) Preserve permissions on Copying, as per comment 2? I'm not sure but I guess we should be consistent here (or use preference). Is there a defect for this? > (2) A "Unix-style" rwxrwxrwx property page is currently in place as UI. Dave > do we have API to replace this with a subsystem-specific UI for more > advanced / different kinds of permissions? At the moment there's no API to replace this unless the org.eclipse.ui.propertyPages extension point lets you override an existing contribution. Can we close this one?
Since this particular enhancement has already been completed, I'm going to close this.
Bug 209593 was fixed in M5 so one could claim that this was also fixed in M5. If there is ever demand for more features we can track these with separate bugs.
