Community
Participate
Working Groups
Created attachment 244177 [details] Screen shot showing the error Steps to reproduce the bug. 1- Install Luna RC4 windows 64 on a network file system. 2- Made the installation directory readonly. 3- Start eclipse. An error has occured see the log file null as shown in the attached screenshot. Furthermore, the following exception is shown in .log file loacted in "<user-home>\.eclipse\org.eclipse.platform_4.4.0_<tag>_win32_win32_x86_64\configuration" !SESSION 2014-06-11 18:05:58.625 ----------------------------------------------- eclipse.buildId=4.4.0.I20140606-1215 java.version=1.7.0_25 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US !ENTRY org.eclipse.osgi 4 0 2014-06-11 18:06:00.715 !MESSAGE Error reading configuration: Unable to create lock manager. !STACK 0 java.io.IOException: Unable to create lock manager. at org.eclipse.osgi.storagemanager.StorageManager.open(StorageManager.java:698) at org.eclipse.osgi.storage.Storage.getChildStorageManager(Storage.java:1747) at org.eclipse.osgi.storage.Storage.getInfoInputStream(Storage.java:1764) at org.eclipse.osgi.storage.Storage.<init>(Storage.java:124) at org.eclipse.osgi.storage.Storage.createStorage(Storage.java:84) at org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(EquinoxContainer.java:75) at org.eclipse.osgi.launch.Equinox.<init>(Equinox.java:31) at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:232) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1465) at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
Do you know if this is a regression in Luna?
If this is a regression it may be related to bug 429921. I don't really understand how this is failing. Here is the code in question: public void open(boolean wait) throws IOException { if (!readOnly) { managerRoot.mkdirs(); if (!managerRoot.isDirectory()) <-------------------- throw new IOException(Msg.fileManager_cannotLock); Above the isDirectory() call is returning false! Before the code used to look like this: public void open(boolean wait) throws IOException { if (!readOnly) { managerRoot.mkdirs(); if (!managerRoot.exists()) <-------------------------- throw new IOException(Msg.fileManager_cannotLock); As you can see we replaced the exists() call to isDirectory() call. I have no idea why the isDirectory() call would return false just after we did mkdirs on it! I had changed to isDirectory() because I had thought we should really make sure it is a directory we just created. This seems to be wrong for some network file systems? Do they really report non-directories for real directories?
This is indeed a regression from Kepler SR2. We will be investigating this some more today.
Created attachment 244188 [details] Screenshot showing the error using Luna-rc2
The issue does not happen with Kepler. It does happen with Luna-rc2, however the error dialog is different (see screen shot above), but the error log is the same: !SESSION 2014-06-12 10:16:17.348 ----------------------------------------------- eclipse.buildId=4.4.0.I20140522-1330 java.version=1.7.0_25 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US !ENTRY org.eclipse.osgi 4 0 2014-06-12 10:16:29.641 !MESSAGE Error reading configuration: Unable to create lock manager. !STACK 0 java.io.IOException: Unable to create lock manager. at org.eclipse.osgi.storagemanager.StorageManager.open(StorageManager.java:698) at org.eclipse.osgi.storage.Storage.getChildStorageManager(Storage.java:1747) at org.eclipse.osgi.storage.Storage.getInfoInputStream(Storage.java:1764) at org.eclipse.osgi.storage.Storage.<init>(Storage.java:124) at org.eclipse.osgi.storage.Storage.createStorage(Storage.java:84) at org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(EquinoxContainer.java:75) at org.eclipse.osgi.launch.Equinox.<init>(Equinox.java:31) at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:294) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:229) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1465) at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
I have debuged that. It seems that the managerRoot.mkdirs() is not creating the complete hirearchy of dirs. It should have created the following hierarchy: "Y:\home\emshham\WDP\.eclipse\org.eclipse.platform_4.4.0_955846538_win32_win32_x86_64\configuration\org.eclipse.osgi\.manager", but it only creates "\org.eclipse.platform_4.4.0_955846538_win32_win32_x86_64\configuration"
(In reply to Hamdan Msheik from comment #6) > I have debuged that. It seems that the managerRoot.mkdirs() is not creating > the complete hirearchy of dirs. > > It should have created the following hierarchy: > "Y:\home\emshham\WDP\.eclipse\org.eclipse.platform_4.4. > 0_955846538_win32_win32_x86_64\configuration\org.eclipse.osgi\.manager", but > it only creates > "\org.eclipse.platform_4.4.0_955846538_win32_win32_x86_64\configuration" This is rather confusing. I'm not sure why mkdirs would not be able to make these subfolders. I have to ask, is the correct user being used that does have write access here?
Maybe related to https://community.oracle.com/thread/1144831
Hamden, Pascal informed my you had diagnosed the issue as being related to UNC paths and that you may have a patch that works around the issue. Could you please share? Marking for SR1.
The problem is that the computed URL for the osgi.configuration.area is inaccurate. Since the user home dir is located on a windows shared drive, the URL representing user home dir is a UNC path. The way osgi creates the URL considers the first part after the "\\" as authority while it should not since the URL designates a file. Example: consider that my user home is located under "\\vhub\hamdan\". When the URL is computed, the vhub is considered as the authority and the path becomes "/hamdan". Eventually, eclipse fails to start since it is unable to create the configuration area under "/hamdan/.eclipse/..." since the user hamdan has write permission only under "/vhub/hamdan/". A patch is provided in here: https://git.eclipse.org/r/29570
(In reply to Hamdan Msheik from comment #10) > A patch is provided in here: > > https://git.eclipse.org/r/29570 Thanks! With your help I now understand the regression. In Kepler the class LocationManager was responsible for computing the shared configuration locations parent [1]. In luna I moved this all around and tried to 'simplify' things by reusing the method Location.createLocation [2] (which is where the bug you fixed is). We did not use this method internally in Kepler. [1] http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.osgi/eclipseAdaptor/src/org/eclipse/core/runtime/adaptor/LocationManager.java?h=R3_9_maintenance#n246 [2] http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.osgi/container/src/org/eclipse/osgi/storage/Storage.java#n109
(In reply to Thomas Watson from comment #11) > In luna I moved this all around and tried to > 'simplify' things by reusing the method Location.createLocation [2] (which > is where the bug you fixed is). We did not use this method internally in > Kepler. > Above I meant to say we did not use Location.getDataArea internally when creating our org.eclipse.osgi locations for the StorageManagers.
Thomas, I am happy to provide this contribution. By the way, there is an if statement in the BasicLocation.getDataArea method which seems to me incorrect: if (filename.length() > 0 && filename.charAt(0) == '/') filename.substring(1); in this method the filename.substring(1); is not assigned. Is that normal?
Fixed in master with commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=098688eb59875add6235ddd1ed9e6c10808c09b2 Still need to backport to Luna SR1.
(In reply to Hamdan Msheik from comment #13) > Thomas, I am happy to provide this contribution. > > By the way, there is an if statement in the BasicLocation.getDataArea method > which seems to me incorrect: > > if (filename.length() > 0 && filename.charAt(0) == '/') > filename.substring(1); > > in this method the filename.substring(1); is not assigned. Is that normal? that does look wrong, I opened bug 439134.
(In reply to Thomas Watson from comment #14) > Fixed in master with commit: > > http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/ > ?id=098688eb59875add6235ddd1ed9e6c10808c09b2 > > Still need to backport to Luna SR1. This fix causes a testcase failure. I had to put a fix in to pass in the correct boolean for trailingSlash otherwise we are always stripping off the trailing slash. http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=58b75a96d093c4cae9e9f4548e81ae241cf8cddb
I pushed the changes to the maintenance branch for Luna: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R4_4_maintenance&id=efb1907e1f2d1cf5ac665683b46529fc6cc0b7a6 http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R4_4_maintenance&id=c3079ebe94a359978e8c297c3082d324004cd3f0 http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R4_4_maintenance&id=e9ea5c1ace50371eecce7d58893e0bcc1be7ffe9 Marking as fixed. This did not make it in time for the M-Build today. Will be in next weeks M-Build unless there is a respin this week for the M-Build.
