Java SE 6和Java SE 8 JRE在Windows 7上的行为有所不同（文件权限）

Question

I have a command line Java application which reads and writes files on Windows 7 x64 platform. Currently application runs with shipped IBM Java SE 6. Structure as follows:

APP_ROOT
    some_folder
    jre
        bin
        lib
    myjarfile.jar
    appl_start.bat 

Now, I replaced the jre folder with unzipped JRE 8 package. And the application started complaining that it can not "access" (actually it's write operation) files in some_folder. If I create manually new some_folder_1 under APP_ROOT and re-configure application to use it - application runs just fine. If I delete newly created some_folder_1 and rename some_folder to some_folder_1 - application complaining that it can't access it (even in read mode).

If I replace jre folder with JRE 6 files - application start working fine.

Tried comparing effective permissions via Properties - all looks the same, nothing suspicious. UAC is turned on, I'm working and doing folders replacement under regular user.

UPDATE : After I turned off UAC in Windows 7 and rebooted, application started working fine with JRE 8. But I need to make it working with UAC turned on. When reverted UAC to on and rebooted - application with JRE 8 failed again. Also, noticed that seems JRE 8 does not create properly files in "C:\\Users\\username\\AppData\\Local\\VirtualStore\\Program Files (x86)\\", where it normally create when program attempts to write inside Program Files.

UPDATE 2 : Did more troubleshooting, and narrowed problem:

1. Application with JRE 8 fails only when it writes to "C:\\Program Files\\APP_ROOT\\some_folder"
2. By Windows 7 design in this case file expected to be created in C:\\User..\\VirtualStore, but JRE 8 can not do this ( which is wrong and the root of the problem )
3. JRE 6 can create files fine in VirtualStore.
4. VirtualStore content was cleaned up before re-run with JRE 8
5. The succeeded run with "some_folder_1" and JRE 8 combination was because JRE 8 actually wrote inside C:\\Program Files/APP_ROOT/some_folder_1 - which is violation IMHO. So, this is another problem - why JRE 8 did not redirect writing to filesystem in the VirtualStore, and modified instead C:\\Program Files subfolder.
6. If I define %localusrdir% to some C:\\temp directory, JRE 8 shows the same problem, so it's not only specific problem of VirtualStore folder, IMHO.

So, I make conclusion - for some reason JRE 8 can not redirect writing output to C:\\Program Files... into C:\\Users...\\VirtualStore

How it can be fixed, so JRE 8 start writing in VirtualStore fine as JRE 6 does?

UPDATE 3 : the failing JRE version:

C:\Program Files (x86)\APP\jre\bin>java.exe -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pwi3280-20150129_02)
IBM J9 VM (build 2.8, JRE 1.8.0 Windows 7 x86-32 20150116_231420 (JIT enabled, AOT enabled)
J9VM - R28_Java8_GA_20150116_2030_B231420
JIT  - tr.r14.java_20150109_82886.02
GC   - R28_Java8_GA_20150116_2030_B231420
J9CL - 20150116_231420)
JCL - 20150123_01 based on Oracle jdk8u31-b12

Answer 1

You don't. JRE 8 is probably telling Windows not to redirect and I'd imagine that's not something you can change. (By the way, automatically redirecting to VirtualStore is a Windows feature, not a Java one.)

VirtualStore is meant for old and misbehaving programs -- not for new ones. You should be storing your data where user/application data is meant to go , and in this case it would be in AppData. If you have existing data (eg this is an upgrade from an old program) then you should migrate the data from that location to a new one that the user can write to.

If you need multiple users to be able to write to the same files then you may have to modify the ACLs / file permissions so that those other users can write to the same files -- this shouldn't require admin rights.

Alternatively, the user could take ownership of / add write permissions to the APP_ROOT but that would require admin rights.

Finally, if you really want to still use VirtualStore, then you can probably detect the JRE version (or make an read/write attempt and catch the exception) and use the VirtualStore path directly, which is likely something you can write to normally if so desired.