Community
Participate
Working Groups
Created attachment 123898 [details] Configuration Log Build ID: I20090129-0100 As per the instructions on http://wiki.eclipse.org/Eclipse/UNC_Paths I tried: * Extract eclipse-SDK-I20090129-0100-win32.zip into \\szg-mober-l1\My @! Folder\I20090127-0100\ * Have three *.link files under dropins/ : org.eclipse.releng.tools.link path=\\\\szg-mober-l1\\My @! Folder\\eclipse_ext\\Releng.Tools\\3.5m4 org.eclipse.cdt.sdk.link path=\\\\127.0.0.1\\My @! Folder\\eclipse_ext\\CDT\\6.0m4 retriever.link path=//127.0.0.1/My @! Folder/eclipse_ext/Retriever/3.1.0.v20090112 * All of these point to valid extension locations, which have been tested OK without using UNC paths * Double click on eclipse.exe * Use workspace at \\SZG-MOBER-L1\My @! Folder\I20090127-0100\workspace --> The bundles referenced by the *.link files get detected and added as "Installable Units in the profile", but they do not get installed. See attached output from Help > About > Configuration Details.
Same problem with the following paths in the *.link files, so this is not an issue of space char or @! characters: path=\\\\szg-mober-l1\\D$\\PDE\\eclipse_ext\\Releng.Tools\\3.5m4 path=\\\\127.0.0.1\\D$\\PDE\\eclipse_ext\\CDT\\6.0m4 path=//127.0.0.1/D$/PDE/eclipse_ext/Retriever/3.1.0.v20090112
Some more observations: 1. After modifying the *.link files to have "normal windows paths" (with drive letter), the bundles still don't get installed. 2. I next replaced the p2/ and configuration/ folders with their original variants from unzipping the SDK, and now I launched Eclpise from \\szg-mober-l1\D$\PDE\I20090127-0100\ Bundles were found and installed as expected. 3. Again, I replaced the p2/ and configuration/ folders with the original. Now I changed the *.link files as follows: path=\\\\szg-mober-l1\\D$\\PDE\\eclipse_ext\\Releng.Tools\\3.5m4 path=\\\\127.0.0.1\\D$\\PDE\\eclipse_ext\\CDT\\6.0m4 path=//127.0.0.1/D$/PDE/eclipse_ext/Retriever/3.1.0.v20090112 On restart, - the releng.tools bundle was installed - the other two extension locations were not installed, but shown as "Installable Units in this Profile"
I replaced the p2/ and configuration/ folders with the original again. Started from \\szg-mober-l1\D$\PDE\I20090127-0100\eclipse with the workspace at \\szg-mober-l1\D$\PDE\I20090127-0100\workspace and the *.link files as path=\\\\szg-mober-l1\\D$\\PDE\\eclipse_ext\\Releng.Tools\\3.5m4 path=\\\\szg-mober-l1\\D$\\PDE\\eclipse_ext\\CDT\\6.0m4 path=//szg-mober-l1/D$/PDE/eclipse_ext/Retriever/3.1.0.v20090112 Now, all my extensions were installed. Odd as it may seem, it looks like p2 doesn't like launching from \\szg-mober-l1 but referencing extensions from \\127.0.0.1 To verify this assumption, I next restored the p2/ and configuration/ folders once again, and launched Eclipse by dbl clicking on \\127.0.0.1\d$\PDE\I20090127-0100\eclipse with the workspace on \\127.0.0.1\d$\PDE\I20090127-0100\workspace --> I got a Windows Security Warning before I could continue --> Eclipse came up as expected --> NONE of my extensions were loaded. Corollary: It looks like p2 doesn't like \\127.0.0.1 in either path= specifier in *.link files, or "current directory" when launching.
Starting from \\szg-mober-l1\My Folder\I20090127-0100\eclipse the "good links" from comment #3 were also NOT installed: path=\\\\szg-mober-l1\\D$\\PDE\\eclipse_ext\\Releng.Tools\\3.5m4 path=\\\\szg-mober-l1\\D$\\PDE\\eclipse_ext\\CDT\\6.0m4 path=//szg-mober-l1/D$/PDE/eclipse_ext/Retriever/3.1.0.v20090112 --> It looks like a space char in the UNC path from which I start already breaks things, OR the "path=" specifier must have the same prefix as the one that I'm starting from (but not the 127.0.0.1 prefix, from which I should not be starting).
After some more investigations, I think I can pin this down to the following: (1) Any kind of UNC paths in *.link files works fine, AS LONG AS Eclipse itself is launched from a path with a "normal drive letter". *.link files tried include: //Server/My @! share/something \\\\Server\\My @! share\\something \\\\Server\\My\ @\!\ share\\something (2) In case Eclipse is launched by dbl clicking from an UNC path, e.g. \\Server\My @! share\somedir then from the *.link files that point to UNC paths, ONLY those will be installed which have the same prefix as the one Eclipse has been started from. Others get added as "Installable Units in this Profile". (3) After a *.link file has been "wrongly detected" due to (2), quitting Eclipse and rectifying the *.link file does not help. It doesn't get picked up any more. The p2/ and configuration/ folders need to be "rebooted" to their pristine state. When Eclipse is then started, it works. So, all the suspects for failure that I had (the 127.0.0.1 address and the special characters) do not seem to cause this issue. What I have not yet tried, is getting a mixture of *.link files pointing to different UNC paths installed properly (by launching Eclipse from a drive letter), and THEN switching to starting the very same Eclipse instance from an UNC path. In case that should work, the workaround is easy (Map a drive letter and launch Eclipse once to get dropins installed; then it works). The one thing that makes this bug more problematic, is that it's possible to "kill" p2 metadata to a state where rectifying something doesn't work any more (and some bundle-to-be-installed won't get installed any more).
(In reply to comment #5) > In case that should work, the workaround is easy (Map a drive letter and > launch Eclipse once, in order to get dropins installed; then, launching > from any UNC path also works). Verified that this does actually work.
(In reply to comment #6) > Verified that this does actually work. Sadly, I need to take this back: While all bundles seem to be installed according to the About Dialog ("About : Plugins"), some bundles seem not to run properly. I don't currently see any pattern which ones run and which don't: - Started from D:\PDE\I20090129-0100\eclipse\eclipse.exe - *.link files with many different patterns under dropins/ --> WTP, DTP, PDT contributions are not visible in the Preference page, although they seem to be installed according to the About dialog. --> At this point, I can only say that using UNC paths for linking extensions via *.link files under dropins/ is broken, but I cannot say why or how. Changing summary, previous value was: [reconciler] p2 doesn't install "*.link" files under dropins/ when some UNC path prefix differs from UNC path on which Eclipse is launched
Martin, could you please see if this is still an issue in 3.5 or 3.5.1. Thx.
Adding polish kwd as discussed on http://wiki.eclipse.org/Eclipse/PMC
This works for me in 3.6 M7. Here is what I did: 1) Unzip Eclipse SDK into \\tpjarthorne\unctest 2) Created a file a.link in dropins folder, with following contents: path=\\\\tpjarthorne\\unctest\\eclipse_ext\\eclemma 3) Unzipped eclemma coverage tool into \\tpjarthorne\unctest\eclipse_ext\eclemma 4) Started the SDK. -> The eclemma tool is correctly installed. It appears in configuration details, and I was able to launch a code coverage session. I can see that the bundles.info has reasonable URLs, for example: com.mountainminds.eclemma.core,1.3.2,file:////tpjarthorne/unctest/eclipse_ext/eclemma/plugins/com.mountainminds.eclemma.core_1.3.2.jar,4,false
Created attachment 167189 [details] Configuration data
Closing.
