FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows [Version 6.0.6000]
i.e. Vista

A DESCRIPTION OF THE PROBLEM :
The current Mustang release note (http://java.sun.com/javase/6/webnotes/index.html) claims that:

"On a Windows OS other than Windows Vista, when running a signed applet, a user is prompted with a security warning dialog box and must respond. If "Yes" is clicked, the applet will have AllPermissions to run on the user's machine. This includes permission to write/delete a file from the local disk.

On a Windows Vista OS, this is no longer true. Instead, AllPermissions is limited to Java Applet scope, not Windows scope. Because a process running in IE has a low integrity level, it will not be able to write/delete a file from a medium/high integrity level directory. "

This is true, but there is a well documented design to allow IE add-ins access the file system from the user's normal (Medium) Integrity level, rather the IE's Low Integrity level: implement an Internet Explorer Broker Process. E.g.  customer  Flash do this (http://blogs.msdn.com/ie/archive/2006/11/17/flash-player-9-update.aspx). Sun need to implement such a process for the IE Java plugin. Without it, Sun's implementation of file access (particularly via the AWT FileDialog) is unusable for ordinary users.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a signed Java applet that accesses the file system outside IE's virtualized file system (e.g. access a file in c:\users\<user name>). Either load, or save a file to this directory. The broker process should be used to access the file, so that the file access works - the current Java plugin lacks this, so the file access is constrained to the IE Low Integrity, which does not have write access to this directory.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Signed Java applets should be able to access all files that a Medium Integrity process can access, rather than just files that IE's Low Integrity process can. Note that this also applies to the AWT FileDialog and Swing file chooser dialogs.

REPRODUCIBILITY :
This bug can be reproduced always.
Posted Date : 2006-12-13 18:22:31.0

To workaround this on Vista, applet can write to the locallow directory instead:

user.home + \appdata\locallow

This should work for both Firefox and IE 7 on Vista.

But then if Microsoft decides to change the locallow folder location later, then this will break.

Or you can use java.io.tmpdir, which will return the user's temp\low directory.  But this is a temporary directory of windows, and we have no control over when will the files get clean up.

A new implementation of the Java Plug-In has been developed which changes the execution model of applets. Instead of running the applets in a JVM embedded in the web browser's process, they are now run in a separate JVM process which communicates back to the web browser. This work was checked in under 6622332. We have received confirmation from outside customers that the new plug-in solves the fundamental problems of running signed applets on Windows Vista. There are certainly still bugs to be fixed in the new plug-in to attain close to 100% compatibility with existing content, but the main problem has been solved.

As of this writing the new Java Plug-In is not yet the default, but will at least ship side-by-side with the current one in the forthcoming "6uN" release, for which early access builds can be found at https://jdk6.dev.java.net/6uNea.html . The new plug-in will be initially available in the forthcoming build 08 barring unforseen circumstances.

Closing this bug as a duplicate of 6622332. Once the new plug-in is available, please try it and file any issues against it under product java, category java_plugin, subcategory plugin2.
Posted Date : 2007-11-08 03:06:20.0

Once the latest JRE 6u10 binary is installed (from http://www.java.net/download/jdk6/6u10/)
- the new "plugin2" architecture has to be enabled via the Java Control Panel.

This is done by:
* Launching the java control panel from the windows control panel
* Clicking on the advanced tab
* Expanding the "Java Plug-in" tree
* And enabling the "next Generation Java Plugin" checkbox

A browser restart is also then required. I've just verified that a new separate java process is started outside the IE process when an applet is launched and others have reported that this new plugin does solve the issues of signed applets not being able to write locally on vista systems.
Posted Date : 2008-01-09 16:12:47.0

I have an applet which opens up File Dialog. When I save a file using that applet anywhere in the disk, it maps it to the virtual store when protected mode is on. Can you give me an ETA for this bug?? When is it likely to fix, and in which version of JRE.

In Vista on IE7, System.getProperty("java.io.tmpdir"), and  System.getProperty("user.home") are not available even from a signed applet when using the AccessControl methods. Therefore, the work around doesn't work.

This work around is not working, I tried it. manually It is allowing us to create the directories but through singed applet it is unable to create any DIR or File.  It seems the signed applet is still unable to write data on disk outside its sandbox in IE7 over Vista :( Plesae verify. i tried alot. It doesnot work. Condition: I donot want to disable UAC.

This is not a suplicate of 6622332. This should not be closed until it has been fixed.

Sorry I have test the latest JRE and I agree this has stil not been fixed, and it is no use at using the workaround as it does help my application, as it has to write updates to program files as it is a signed applet, when is the broker process going to be implemented?

this is incredible, as it seems, since SUN marked it as duplicate, it's not even planned to be fixed... does that sound even an option that signed applets will not have access to the file system but only to a virtual one, where are you SUN guys ? this eliminates so much power from java applets....