Community
Participate
Working Groups
The update manager uses default Java I/O support to copy files. This seems to create all files with rw- permissions. On some systems shared libraries need x (execute). Having w in a shared install is also a problem.
We also are shipping on linux and need to ensure that file permissions never get lost during updates.
I agree this needs to be fixed, but please justify how this is a blocker. The only supported system where this was preventing Eclipse from working was HP-UX and 2.0 contains a temporary fix for HP-UX for this.
If the description is correct then it is a blocker. If all files are having their permissions stripped and reset to rw (i assume rw for all users -rw-rw- rw?) Then WSAD has a couple of problems. Our shell scripts and executables contained in plugins we update won't run without the execute bit set. This is true for WSAD as well as the ClearCase plugin which relies on executable perl scripts to function. This is blocking for that reason.
The fix needs to be the correct fix as well. It is impossible to detect whether a file was executable after stripping the execute bit. I don't know what the temp fix for HP was. Hopefully it wasn't to set the execute bit on files that had a particular extension. If so that was a dangerous assumption. The extensions of shared libraries are a convention not requirement. Many shared libs don't have extensions or have extensions that are not .so. So it may work for eclipse's shared objects but not others.
Peter, can you confirm installp and rpm have a filset list that lists the permission of the files during install... do you have doc about this ?
We will fix the problem in 2.0.1 in the following way: A Java properties file called 'permissions.properties' will be required for plug-ins that contain files that need to be executable on UNIX operating systems. The file will be looked for in the plug-in root. The syntax for the file will be very similar to that of build.properties. A single property 'permissions.executable' will be used to list files that need to be executable. Files are listed in the comma-separated list in the value portion of the key/value pair. Wildcard * is permitted. Post 2.0.1, we may introduce more properties for a more specific post-install file fixup. For 2.0.1, files that match permissions.executable value will have their executable bit set. The effect is equivalent to running 'chmod' command with '+x' argument. The command will be run using Runtime.exec' in 2.0.1 to avoid regressions. Example of a permissions.properties file for SWT fragment org.eclipse.swt.motif: #Permissions used by the Install/Update on platforms that depend on it permissions.executable = os/aix/ppc/*.a,\ os/hpux/PA_RISC/*.sl,\ os/linux/x86/*.so,\ os/solaris/sparc/*.so Note that in reality only hpux libraries need their executable bit set. The file needs to be placed in the fragment root directory. Post 2.0.1, native code will be written to call chmod function from unistd.h ANSI C library. This will make the code execute faster. Performance is not an issue with a handful of files that need their executable bit set (as defined in permissions.properties). However, if all the files that are installed have their permissions set, it becomes a problem. Using a native call will make it possible to fix permissions on ALL the installed files to be rw-r--r-- (as opposed to the pure Java behaviour that results in rw-rw-rw- when creating new files). Bottom line: For 2.0.1, all files installed by Update component will have rw-rw-rw- permissions except for files listed in permissions.properties that will have rwxrwxrwx. After 2.0.1, native code calls will be used to change permissions for all the files to rw-r--r--, and rwx-r-xr-x for files listed in permissions.properties.
Verified using 2.0.1 build 0821 (the build required manual addition of permissions.properties into org.eclipse.swt.motif - see defect http://dev.eclipse.org/bugs/show_bug.cgi?id=22729 - but the problem is in SWT and will be addressed in the suqsequent build).
