Comment 1 Pascal Rapicault 2006-12-19 08:42:30 EST

CC'in Felipe as he may have seen that on Vista.

Comment 2 Steven Wasleski 2007-01-09 10:35:30 EST

It looks like you were using the Nov 22nd 3.2.2 build.  Could you try this on the latest. Others have been running later builds successfully on Vista.

If this really is still a problem we will need to look at it for 3.2.2.

Comment 3 Thomas Watson 2007-01-09 15:29:30 EST

Andrew, can you verify that the framework successfully extracted the swt-win32-3235.dll library to the configuration are.  There should be an org.eclipse.osgi/bundles directory under your configuration directory.  The default location of the configuration directory is the eclipse install directory (i.e. where eclipse.exe is located).  Please search that directory to see if the swt-win32-3235.dll exists on disk.  Thanks.

Comment 4 Tod Creasey 2007-01-10 11:28:49 EST

I am running 3.2.2 from M20070103 on the Vista Enterpise release without this issue

Comment 5 Thomas Watson 2007-01-10 11:30:49 EST

It appears this may have been an issue with the older build you were using.  This works for me on the latest 3.2.2 builds.  Please re-open if you are still seeing issues on the latest 3.2.2 build from M20070103.  Thanks.

Comment 6 Andrew deBlois 2007-01-10 17:44:24 EST

It appears that the problem is related to where Eclipse is located.  When the Eclipse directory is on the desktop, things work fine.  When I put the Eclipse directory in the Program Folders directory, I see the failure as noted in the report.

I'm using the 20070103 build and am running as an administrator on the machine.

Comment 7 Thomas Watson 2007-01-10 17:53:58 EST

Andrew, can you answer questions from comment 3 please?

Comment 8 Thomas Watson 2007-01-10 18:16:36 EST

I think this may have something to do with the permissions of folders under the
Program Files directory on Vista.  When I attempted to reproduce this I found
that eclipse could not write to the default configuration directory if it was
under the Program Files directory.

It looks like Vista is very particular about writing to the Program Files
directory now.

Comment 9 Andrew deBlois 2007-01-10 22:04:03 EST

The configuration directory did not contain the dlls and was not expanded when the Eclipse directory was under the Program Files folder.  When Eclipse was run from a directory on the desktop, things worked fine and the configuration directory contained the expanded set of folders.

Yes, there seems to be some permission problems when running inside the Program Folders directory.  Creating a new file in the Eclipse directory if it is under the Program Files folder requires confirmation from the user before the action is allowed.  I'm not sure how this confirmation is done programmatically or if this is what is getting in the way of expanding/creating the folders in the configuration directory.

Comment 10 Andrew deBlois 2007-01-11 09:51:45 EST

It appears that Vista is redirecting the writes to the Program Files folder into the user's area.  I found the configuration directory under: 
C:\Users\admin\AppData\Local\VirtualStore\Program Files\...\configuration

Would Eclipse be able to check this area if running on Vista within a "privileged" directory?

Comment 11 Thomas Watson 2007-01-11 10:41:39 EST

hmmm...  Does the configuration folder under your user directory contain any cached data?  If so then it seems like Vista is redirecting writes but not reads?

Comment 12 Steven Wasleski 2007-01-11 12:14:31 EST

Some additional information I found via Google:

Visual Studio 2005 has the same problem on Vista (http://msdn2.microsoft.com/en-us/vstudio/aa972193.aspx).  Apparently you have to run with administrator permissions to avoid the problem.  I don't think that would be an acceptable work around for many products.

Other links:
http://www.west-wind.com/WebLog/posts/5584.aspx - appears to explain why the dll went where it did.  Does not address the read issue.  Hints at a possible work around involving adjusting permissions on the folder into which eclipse is installed.  This one might be more acceptable.

http://technet.microsoft.com/en-us/windowsvista/aa905073.aspx - Some official Microsoft information that I did not have time to wade thought but may be helpful.

Comment 13 Andrew deBlois 2007-01-11 12:21:37 EST

Apparently, the problem is related to the run level of the application once it is installed and not the privileges of the user running the application.  I was running as administrator.

I'm a bit puzzled why this mechanism of redirecting reads and writes is failing with Eclipse since the configuration directory is getting created correctly in the user space.  The reads should have been redirected to the user space as well and the forrect swt library loaded.  I'm wondering if this is a problem with the JRE somehow performing reads that are not getting redirected.

Comment 14 Steven Wasleski 2007-01-11 13:09:07 EST

Another valuable link:
http://blogs.msdn.com/aaron_margosis/archive/2006/06/19/638148.aspx - I particular, note this comment from the blog author to a comment from a reader, "DLL redirections shouldn't be a problem -- Vista's file virtualization is not applied to executables (.exe, .dll, .ocx, etc.).".  I think this may explain the read problem.  Apparently the creation of any file will be virtualized but it will not run virtualized executables.

Comment 15 John Arthorne 2007-01-11 17:06:35 EST

DLLs are not virtualized.  See appendix F of:

http://www.symantec.com/avcenter/reference/Windows_Vista_Security_Model_Analysis.pdf

And a simple test:

		File file = new File(
				"c:\\Program Files\\test.dll");
		FileOutputStream fout = new FileOutputStream(file);
		fout.write(5);
		fout.close();
	
Fails with:

java.io.FileNotFoundException: c:\Program Files\test.dll (Access is denied.)
	at java.io.FileOutputStream.open(Native Method)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:205)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:157)
	at p1.VistaDLLTest.main(VistaDLLTest.java:26)


If I change "test.dll" to "test.all" in the above program, it does not fail because it virtualizes the file.

Comment 16 John Arthorne 2007-01-11 17:11:41 EST

The Microsoft guidelines for Vista state (third link in comment #12):

Applications should be installed in the \Programs files\ directory. Per-user configuration information should be stored in the \Users\(username)\AppData directory. User data, templates, and application-created files all have proper locations in the \Users\(username) subdirectories. Although this was not enforced in the past, since many users would run programs with full administrative privileges, applications that do not place information in the correct location are likely to fail. This is especially true when Virtualization is turned off.

I think our best long term solution is to change the default location of the configuration directory to be under user home dir, at least on Vista.  As a workaround for 3.2.2, there are a number of options:

1) Don't install Eclipse under Program Files
2) Run Eclipse as administrator
3) Run Eclipse as administrator at least once, until all DLLs are extracted. Then you can run as regular user
4) Use -configuration command line argument to redirect config directory to user home.

Comment 17 Thomas Watson 2007-01-11 18:04:30 EST

John's analysis is correct.  I confirmed the same exception is occurring in the Framework when it tries to extract a .dll to "Program Files".

I tried to use a different extension to extract the .dll (I just appended .test).  This allowed the library to be extracted to a <library>.dll.test file but then the VM throws an exception trying to load a dll from a file that does not have a .dll extension.  For 3.2.2 you will need to configure eclipse to use a configuration in a writable (non-virtualized) directory.

Comment 18 John Arthorne 2007-01-12 09:44:21 EST

I'll write up some words for the readme for 3.2.2.

Comment 19 Andrew deBlois 2007-01-12 13:02:45 EST

Running Eclipse as an administrator still showed the same problem since
the application still runs with user privileges.

One workaround might be to modify the default config.ini to include the osgi.configuration.area tag to point to the users's home area:

osgi.configufation.area=@user.home/configuration  (or something like that...)

I'm a bit concerned about how Eclipse will handle upgrades using the Install/Update manager.  Will this require updates to the Program Files are?
How is this handled on UNIX systems when users' don't have access to the
installation directory?

Another option may be to include a manifest file in the installation directory
to run Eclipse with administrator privileges - this probably isn't the best
practice but might be a workaround: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=723991&SiteID=1

Comment 20 John Arthorne 2007-01-12 16:03:54 EST

Vista distinguishes between a user account with administrator privileges, and the Administrator user.  The problem still occurs when running as a user with administrator priveleges, although it does give you the option in this case to run the application as administrator.  If you log into your machine as the Administrator user, the problem does not seem to occur (at least on the machines we tested).

The difference from the Unix case is that it's more difficult to detect the situation.  On startup, we do a java.io.File#canWrite test. If the file is not writable, we write configuration data in the user's home directory instead. On Vista this returns true for all users, because Vista virtualizes writes to "Program Files" into a directory in the user's home directory. Anything written to Program Files is written to a different directory, with the exception of executable files such as DLLs.  I.e., the directory claims to be writable, but writing a DLL fails. We will likely investigate a solution that involves properly detecting this condition (for example by checking if we are on Vista).

We might be ok for update, since updates will be installed in the virtual directory for the user.  The net result is that only the user who installed the plugin will see it.  This can be viewed as a feature ;)  However, we'll need to do more testing to verify there are no other issues with install/update on an Eclipse installed under Program Files on Vista.

Comment 21 Andrew deBlois 2007-01-19 15:02:22 EST

We've been able to work around the problem by modifying the config.ini file
so that the configuration information is written to the user's area:

>
> osgi.configuration.area=@user.home/my_config
>

Do you see any problems with using this approach for now?

Comment 22 Alex Blewitt 2007-02-10 20:41:21 EST

Guess what ... the Mac users have been saying exactly the same thing for ages. Get the configuration area out of the program's install location and into a (writable) subdirectory of the user's home directory instead.

Comment 23 Stanimir Stamenkov 2007-02-17 09:41:35 EST

(In reply to comment #21)
> osgi.configuration.area=@user.home/my_config
> 
> Do you see any problems with using this approach for now?

I'm not on Vista but on XP and I've used the above approach for very long time.  The only problem I've found is the main installation directory becomes "locked" (I see a chain like icon decoration for the main install location in the Manage Product Configuration dialog) even when running with Administrator privileges for the purpose of updating the main installation - I have to commend out temporary the above configuration line.

Comment 24 Elliotte Rusty Harold 2007-02-22 10:31:25 EST

I'll echo what Alex said: this is not a platform specific bug. Configuration data should be separated from the application install location, period. All platforms Eclipse runs on support multiple users who may have different preferences, plug-ins, and configurations. Only core files should go into the Applications directory (or whatever that is called on Windows).

Even on Windows, this isn't just a problem on Vista either. I've had trouble using Eclipse for hands-on courses with Windows XP because the lab computers locked the directory where Eclipse was installed. 

Someone with the right privileges please change the hardware and OS fields on this bug to All.

Comment 25 John Arthorne 2007-02-22 10:40:27 EST

Elliotte, see comment #20 for an explanation of why this particular bug is unique to Vista.

Comment 26 Philippe Verdy 2007-03-12 13:12:31 EDT

Time to raise the priority for Vista users: most advanced PCs sold today with decent performance for application development (memory, large disk space, fast processor) are shipped with a Vista licence. Having to buy a XP licence jsut to get the standard Eclipse framework (and its regular updates) will be just more money given to Microsoft.

So define a clear installation framework so that Eclipse can be installed safely on Vista. May be it will be necessary to include a Eclipse installation plugin that will check in its API the security before imporsonating itself to copy some files in its installation directory (notably for the Eclipse software updates, or when a Eclipse plugin needs to extract some JNI implementation DLL in one of its plugin directories.

Having to nistall Eclipse in a user directory is a bad option: many systems have multiple user accounts, and Eclipse is taking significant space on disk: why couldn't its installation be shared between users?

Couldn't it be installed with its plugins/updates directory in the "All users" directory (where it will be read-only for regular users privileges, except for the Eclipse installation plugin performing impersonation before chaging the plugin/updates content).

It this is not possible, then have the Eclipse installation allowing to add read-access privileges to its user installation directory, so that we can only keep one shared copy of the IDE. Remember also that Eclipse must remain manageable on a network: a domain admin may connect to the system to maintain the list of plugins, patches and updates of an Eclipse environment, and the normal developer will not modify this installation but will only work in his own projects.

The current suggestion of installing Eclipse in normal user space is not very good, also because because Eclipse is quite large, and will consume lots of the normal user quotas (needed for central backup of user spaces: the enterprise backup system may not accept that each developer installs many megabytes in their user space; so admins will have to manually exclude some parts of the installation directory in user spaces). Also, some environments are getting the user environment from the network within a local cache. Eclipse is too large to fit there and so it will take considerable time to load locally from the network.

So we need LIGHT user environments, not environments with tons of megabytes to administrate for each user on each PC of a LAN.

Comment 27 Philippe Verdy 2007-03-12 13:33:09 EDT

Time to raise the priority to P1 for Vista users: most advanced PCs sold today with decent performance for application development (memory, large disk space, fast processor) are shipped with a Vista licence. Having to buy a XP licence just to get the standard Eclipse framework (and its regular updates) will be just more money given to Microsoft. Eclipse should not depend on which OS is used but should work on whatever OS users already have.

So define a clear installation framework so that Eclipse can be installed
safely on Vista. May be it will be necessary to include a Eclipse installation
plugin that will check in its API the security before imporsonating itself to
copy some files in its installation directory (notably for the Eclipse software
updates, or when a Eclipse plugin needs to extract some JNI implementation DLL
in one of its plugin directories.

Having to nistall Eclipse in a user directory is a bad option: many systems
have multiple user accounts, and Eclipse is taking significant space on disk:
why couldn't its installation be shared between users?

Couldn't it be installed with its plugins/updates directory in the "All users"
directory (where it will be read-only for regular users privileges, except for
the Eclipse installation plugin performing impersonation before chaging the
plugin/updates content).

It this is not possible, then have the Eclipse installation allowing to add
read-access privileges to its user installation directory, so that we can only
keep one shared copy of the IDE. Remember also that Eclipse must remain
manageable on a network: a domain admin may connect to the system to maintain
the list of plugins, patches and updates of an Eclipse environment, and the
normal developer will not modify this installation but will only work in his
own projects.

The current suggestion of installing Eclipse in normal user space is not very
good, also because because Eclipse is quite large, and will consume lots of the
normal user quotas (needed for central backup of user spaces: the enterprise
backup system may not accept that each developer installs many megabytes in
their user space; so admins will have to manually exclude some parts of the
installation directory in user spaces). Also, some environments are getting the
user environment from the network within a local cache. Eclipse is too large to
fit there and so it will take considerable time to load locally from the
network.

So we need LIGHT user environments, not environments with tons of megabytes to
administrate for each user on each PC of a LAN.

Additionally, may be it's time to think about developing a security fromework
for the deployment of Eclipse and its optional plugins. For now Eclipse
security is managed only as a whole (very large) object; as time tpasses, the
whole Eclipse system provides advanced services that will need to be secured;
so the security model of Eclipse should be studied again, by allowing various
scheme of shared/user security schemes, with globbal/network/local
authentication schemes.
Vista offers all these options to manage the security features (and privileges)
for each kind of object. Java's core also implement such thing (through secured
class loaders actnig as isolation boxes). We will also see more and more
services deployed ni a decentralized way, within a network of delocalized peers
that can be managed and deployed transparently for scalability of services.
In other words, Eclipse lacks such security management framework, including for
network services (like Eclipse plugin servers).
Finally, Eclipse should reduce significantly its dependency to JNI
implementation components; this really does not ease the deployment on servers
and it wil be always difficult to manage their security (because the internal
code of JNI implementation libraies can't be checked easily except by digital
signatures or MD5/SHA1-like secured hash checksums). Most of the JNI components
are needed only because Eclipse's core environment (or the JRE itself) lacks
some integration features, but these system integration features are now being
migrated regularly and generalized within the JRE, and Eclipse plugins should
need them less often, given that the corresponding APIs will be able to use
standard general services of the JRE with simpler security management.
For this reason, any new security framework in Eclipse should be completely
compatible with the existing JRE security mechanisms in J2SE, J2ME ou J2EE
environments. We can do a lot now with the JRE 6 platform because most system
integration features are integrated there; plugins just need to use them as
much as possible instead of reimplementing them in their JNI implementation
libraries... Let's come back to 100% Pure Java plugins...

Comment 28 John Arthorne 2007-03-14 10:15:36 EDT

Philippe - please be patient, a fix for 3.3 is being investigated. We are aware that asking users to install Eclipse-based applications outside of Program Files on Vista is not an acceptable solution. However, a pervasive new security framework or elimination of plugins using JNI is not in the cards.

Comment 29 Thomas Watson 2007-03-14 13:32:51 EDT

Created attachment 60830 [details]
patch

This patch does two things

1) When performing the test for canWrite it uses a file with a .dll extension.  This will fail on a virtualized directory on Vista with an IOException.  This will cause the launcher to use a configuration under the user.home.

2) When computing a configuration directory under the user home we currently look for a .eclipseproduct file to determine the product id and version.  This is used to create a "unique" configuration directory.  But this can cause problems if you have the same product id installed in more than one location.  The patch adds an additional hash to the configuration directory based upon the install location.

This works well on my Vista machine.  John A. can you try this out on your Vista installation?

We have another issue that we need to consider regarding update.  Currently update defaults to installing new bundles into the install area.  I suggest we open a separate bug for that issue if one is not already opened.

Comment 30 Thomas Watson 2007-03-15 15:25:37 EDT

Created attachment 61005 [details]
patch

This patch uses the canonical path first and falls back to the absolute path of the install dir to compute the hash.  This is needed to handle paths with different cases on windows and linked directories on linux.

Comment 31 Thomas Watson 2007-03-15 15:54:05 EDT

Created attachment 61010 [details]
patch

I just realized that we have the exact same bit of code in LocationManager in org.eclipse.osgi.  This code is used when launching the framework standalone or embedded in another application.  This patch includes fixes to both the launcher and osgi.

Comment 32 Thomas Watson 2007-03-16 15:29:28 EDT

Created attachment 61153 [details]
patch

Disregard the last patch.  It was against the wrong projects.  Here is the correct one.  I'm going to release this for M6.

Comment 33 Thomas Watson 2007-03-16 15:35:26 EDT

Release fix for M6.

Bug 90630 is being used to track the issues in update.

Comment 34 John Arthorne 2007-03-20 11:26:32 EDT

Verified in I20070320-0010.  Installing in Program Files, and running as non-administrator, the configuration directory was written in the user home directory.  Running as administrator, the old behaviour of writing the configuration directory under the install tree occurred. We may want to consider using user home as the default location for all platforms in a future release, but the goal of this fix was to address the Vista problem without introducing disruptive changes.

Comment 35 Thomas Watson 2007-11-02 11:52:35 EDT

Created attachment 81974 [details]
3.2.x patch

Here is the same fix for the 3.2.x stream.  Notice that the startup.jar contains the fix since we did not have an org.eclipse.equinox.launcher in 3.2.

Comment 36 Nalini Ganapati 2007-11-28 17:30:17 EST

startup.jar is part of the org.eclipse.platform.launcher feature in the bin directory. org.eclipse.platform.launcher feature is used when building rcp applications and startup.jar should be patched in this feature too. Can we expect a patch for the org.eclipse.platform.feature for 3.2.2?

Comment 37 Thomas Watson 2007-11-29 08:47:28 EST

Bug 209192 released the fix into the 3.2.x stream.

Comment 38 Shubhvardhan 2008-02-28 08:43:24 EST

I have a similar case with an eclipse rcp which can be launched in 2 different
modes (using 2 different config.ini files located in /configuration and
/config2 folders)

both these files are located in the eclipse install location - which may not be
writable.

To launch the second configuration, If I use:

1. eclipse -configuration config2 , the runtime configuration gets written to
/config2 (Irrespective of any variables set inside /config2/config.ini)

2. eclipse -Dosgi.sharedConfiguration.area=config2 , the runtime configuration
gets written to the osgi.configuration.area specified in
/configuration/config.ini

What is the best way to launch config2 using /config2/config.ini as the
configuration file and @user.home/temp to store the runtime configuration data

note: the 2nd launch works fine, but if I use a -debug switch as well, i see that the /configuration folder and the enclosed config.ini is picked up as a launch configuration even though nothing is written into /read from this at run time. But I dont want /configuration to even come into the picture. cascaded=false doesn't help