Bugzilla – Full Text Bug Listing
| Summary: | unwanted directory automatically created at the file system root | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] EPP | Reporter: | Laurent Goubet <laurent.goubet> | ||||
| Component: | Packager | Assignee: | Project Inbox <epp.packager-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | cedric.brun, count.negative, darryl, dh_tue, irbull, jensseidel, mhilpert, mknauer, ordinant, overholt, pascal, pwebster, remy.suen, rosti.bsd | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 1.4.0 RC1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=273821 https://bugs.eclipse.org/bugs/show_bug.cgi?id=336843 |
||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Laurent Goubet
Okay, the /opt/... folder doesn't get created as soon as I launch Eclipse : it gets created when I install something from the Helios update site (reproduced by installing the Subversive SVN team provider). A colleague of mine told me a like-named folder was already created with the galileo epp package on a random basis (even though he deletes it each time he sees it on his file system)... I'd say this issue has been there for a good while. That's very interesting! Thanks for bringing this up. There is another bug report (bug 273821) that is very similar to this one here. Two things seem to be worth mentioning here: It looks as there are no side effects other than the creation of the artifacts.xml file and file not found entries in the log. Second, the error seems to exist since Galileo (at least). Moving to 'Packager' since I assume that all packages are affected. This bug report here and bug 273821 are describing a (maybe underestimated?) problem that seems to exist since Galileo. In Helios I thought it is fixed, but now it turns out that it is still existing. One question is now: Is it only *annoying* or is it even *critical*? In my own tests (install, update, upgrade from 3.5 to 3.6, ...) I never saw any errors or problems in the EPP packages caused by this. And the other question: Where is the difference (if any) in the build process between the Eclipse (Classic) SDK and the EPP packages? Or is there a bug somewhere in the org.eclipse.equinox.p2.director application? As far as I am concerned, this is "only" annoying ... as far as we can say "only" when a program messes up with the file system on its own. I haven't seen any issue with deleting the "g:/opt" folder altogether, it would be a little less easy in linux if the EPP package simply decided to put its "artifact.xml" somewhere in my "/opt" folder... does a non-root user even have write access in that folder? (Haven't got a linux distro at hand with this machine.) On my system the folder gets created too (Vista 32bit) and it's annoying AND demolishes my trust in eclipse. What about file system rights? What about deinstalling if not on Windows? What about the files we don't see that are created/overwritten/deleted on my system. Where was qa? I believe that eclipse has since 3.5 some serious quality problems. I'm going to have to agree with count.negative's comments. It's rude and unprofessional to drop some random file in the user's file system that's not related to the target installation. The /opt path in this dropped file makes it clear that someone was making the usual everyone-uses-Linux-nowadays-anyway assumptions. Related ??? https://bugs.eclipse.org/bugs/show_bug.cgi?id=273821 https://bugs.eclipse.org/bugs/show_bug.cgi?id=326642 Blogs and other reports: http://www.google.co.uk/search?source=ig&hl=en&q=eclipse.S-3.6RC4-201006031500 > And the other question: Where is the difference (if any) in the build process
> between the Eclipse (Classic) SDK and the EPP packages? Or is there a bug
> somewhere in the org.eclipse.equinox.p2.director application?
The SDK uses an external director to perform the installation (of course the SDK does not exist before this time) therefore repos being used are not persisted in the install. If the EPP packages are built using the director shipped in the SDK (or the platform), then this behaviour can be explained.
Markus, to confirm, could you please try to build an EPP package using an "external" director and report as to what you see. Thx
*** Bug 326642 has been marked as a duplicate of this bug. *** Appears in Helios Service Release 1 @t PC WinXP(x64) Appears in Eclipse 3.6.2 JEE build as well. The C:\opt\public\... was created after an Eclipse update has been installed. OS: Windows XP Professional, SP3, 32-bit. Java: Oracle JDK 6u24 I just recreated this error with simple steps: 1. No C:\opt directory is present 2. Run Eclipse 3.6.2. My base installation is the RCP-RAP package. 3. Run Help > Check for Updates AND An EPP RCP/RAP feature had an update available for me to install. 4. Now there's a C:\opt directory with path to artifacts.xml. This is before I actually ran the update. The path and file are created just by checking for the update and finding one waiting. These steps do NOT get C:\opt created when there is no update waiting. I followed the steps in comment #12 and was able to reproduce the problem. The C:\opt\public\technology\epp\epp_build\36\eclipse.R-3.6.1-201009090800 folder was only created when I did the install though, not when I checked for updates. When I looked in the profile registry, there are 2 profiles SDKProfile and epp.package.rcp.profile. Here are some of the property values set in the SDKProfile (which lead to the creation of the bad location): <properties size="11"> <property value="/opt/public/technology/epp/epp_build/36/eclipse.R-3.6.1-201009090800" name="org.eclipse.equinox.p2.installFolder"/> <property value="/opt/public/technology/epp/epp_build/36/eclipse.R-3.6.1-201009090800" name="org.eclipse.equinox.p2.cache"/> <property value="/opt/public/technology/epp/epp_build/36/eclipse.R-3.6.1-201009090800" name="org.eclipse.equinox.p2.cache.shared"/> <property value="/opt/public/technology/epp/epp_build/36/eclipse.R-3.6.1-201009090800/configuration" name="org.eclipse.equinox.p2.configurationFolder"/> <property value="/opt/public/technology/epp/epp_build/36/eclipse.R-3.6.1-201009090800/configuration/eclipse.ini.ignored" name="org.eclipse.equinox.p2.launcherConfiguration"/> </properties> Markus, I would suggest trying Pascal's suggestion in comment #8. Moving to the next milestone, Indigo M7. I want this long-existing bug to be fixed with Indigo. I think I found the error... The director call that assembles the packages from the p2 metadata contained a VM parameter that sets the p2 data area:
-Declipse.p2.data.area=${PACKAGE_BUILD_DIR}/eclipse/p2
This parameter seems to advice the director application (in that case the one taken from the Eclipse SDK, therefore the SDKProfile) to 'update' its own profile within the package that it is building.
*** Bug 336843 has been marked as a duplicate of this bug. *** *** Bug 273821 has been marked as a duplicate of this bug. *** I am not able to reproduce this any more, seems like the above change did the trick. Closing this bug as FIXED. |