Bugzilla – Full Text Bug Listing
| Summary: | Config-Location dosen't work correkt on network-devices | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Heiko Techteam <techteam> |
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | mober.at+eclipse, tjwatson |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
|
Description
Heiko Techteam
Now I talked to the administrator and also test together with him, but doesn't found a reason to this error. Under Eclipse 3.5: RCP Application with a view -can generate and use the defined configuration directory (-configuration) -can generate and use the defined instance directory (-data) Under Eclipse 3.6RC4: RCP Application with a view -can generate the defined configuration directory (-configuration) -afterwards creates an errorMessage: The configuration area at 'M:\<Path>' is not writeable. ... -can generate and use the defined instance directory (-data) Because of I dont have a possibility to install an IDE inside our produktion system, I would write a small test app to specify the error more. But at the moment I dosent found the point inside the code where the platform generate the config-area and check if it writable. If somebody point me where I can find the code parts I will try to find out more. This check is done in the launcher at: org.eclipse.equinox.launcher.Main.checkConfigurationLocation(URL) It appears that the user cannot write to the configuration folder according to the method: org.eclipse.equinox.launcher.Main.canWrite(File) One possible workaround is to set the following property in your config.ini or eclipse.ini (launcher.ini). osgi.configuration.area.readOnly=true See bug301226 for a discussion on the changes in this area for 3.6. Are you sure the configuration folder is getting created by the user running the instance of eclipse? If so I don't see how or why that configuration folder would not be writable by that user. Martin, not sure if there is an issue with how we check canWrite here. (In reply to comment #2) > This check is done in the launcher at: > > org.eclipse.equinox.launcher.Main.checkConfigurationLocation(URL) > > It appears that the user cannot write to the configuration folder according to > the method: > > org.eclipse.equinox.launcher.Main.canWrite(File) > This method helps me: The reason why I cant write is the File.createTempFile("writetableArea", ".dll", installDir) Our security policies (and also I think in many other organisatzions) doesn't allow to write / create executable or dll files. Both version of Eclipse 3.5 and 3.6 try at startup to unpack also the swt dll's but if it fails 3.5 has no problem with this. With 3.6 it's not possible to do that because before it fails on the filecheck above. If I see right and this createTempFile - option for vista will not be changed my options are on one side to generate my own launcher package or I have furthermore to use 3.5 :( (In reply to comment #4) > Both version of Eclipse 3.5 and 3.6 try at startup to unpack also the swt dll's > but if it fails 3.5 has no problem with this. > With 3.6 it's not possible to do that because before it fails on the filecheck > above. On 3.5 you are likely able to run SWT because of a fallback in SWT when if fails to load the swt dll. When this happens the SWT java code will attempt to extract the dll its self into the user's home directory and load it from there. This is likely not what you expect or want either. Also note that other bundles that have native code do not implement such a fallback and will fail to load their native code also. > > If I see right and this createTempFile - option for vista will not be changed > my options are on one side to generate my own launcher package or I have > furthermore to use 3.5 :( I doubt we will want to change the canWrite logic in this area. We make assumptions on being able to write to the configuration area. In 3.6 we changed the logic to fail fast because we ran into too many issues where strange exceptions would happen later and they are very hard to debug and explain. (In reply to comment #4) > The reason why I cant write is the > File.createTempFile("writetableArea", ".dll", installDir) > > Our security policies (and also I think in many other organisatzions) doesn't > allow to write / create executable or dll files. This is not related to the changes that we contributed for Eclipse 3.6 -- the logic for testing write of a DLL had been in there before (and we found it pretty odd). I'm not sure who owns that check, but I can understand the bug submitter's point that it should be sufficient to write "data" to the config area. Denying startup because of this DLL check is a regression and should be addressed. I'm not sure what (if anything) should be done here, but here are some random thoughts: - Improve error message such that different messages are reported for "not writable" versus "failed to create .dll" - Be less strict on the "failed to create .dll" error, e.g. provide a System Property to ignore this error (because some RCP's may never need to write a .dll there, yet the error blocks them from running their RCP) - Could it help to run the RCP once with a "-initialize" switch on a shared configuration location, such that the .DLL is already extracted in the shared location and writing it to the user's config area is no longer necessary - Defer the "failed to create .dll" error to when the dll is actually created - Generalize the SWT workaround, i.e. allow specifying a separte fallback location for where DLL's can be written Not sure what (if anything) of this would make sense. > > Both version of Eclipse 3.5 and 3.6 try at startup to unpack also the swt dll's > but if it fails 3.5 has no problem with this. > With 3.6 it's not possible to do that because before it fails on the filecheck > above. > > If I see right and this createTempFile - option for vista will not be changed > my options are on one side to generate my own launcher package or I have > furthermore to use 3.5 :( (In reply to comment #6) > (In reply to comment #4) > > The reason why I cant write is the > > File.createTempFile("writetableArea", ".dll", installDir) > > > > Our security policies (and also I think in many other organisatzions) doesn't > > allow to write / create executable or dll files. > > This is not related to the changes that we contributed for Eclipse 3.6 -- the > logic for testing write of a DLL had been in there before (and we found it > pretty odd). I'm not sure who owns that check, but I can understand the bug > submitter's point that it should be sufficient to write "data" to the config > area. Denying startup because of this DLL check is a regression and should be > addressed. > I do not view this as a regression. Perhaps a change in behavior, but a correct change in my opinion. The framework assumes it can use the configuration area as a place to extract native code. If it can not do that then we should fail early. To do otherwise leads to strange and unexpected failures later. Thanks for your answers. Now I know where are the problem and have to see how can I solve it. I can understand your reason of this check but I also hope your can understand my problem with this. My organisation and I think for example some other german governmental authorities will have a problem with this by the defined security policies. Today I try the tip with the "-initialize" parameter at first startup by an administrator, but this works also not correct at the moment. I will test it again tomorrow. Finally if I get solved it or not, in my hole opinion, this new check should be documented in the incompatibilities list of 3.6. 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. -- The automated Eclipse Genie. No plans to address this. |