Inno Setup constant equivalent for System.getProperty("user.home") - java

I'm storing a preferences file for bundled JavaFX app under user directory, which I create at Runtime using
System.getProperty("user.home")
I want to order InnoSetup to delete that file at uninstall, but I can't find appropriate Inno Constant.
Please, advice.

On Windows, user.home maps to %USERPROFILE% environment variable, what is typically C:\Users\username.
There's no equivalent constant for that in Inno Setup. Probably because you are not supposed to store any files there. You should store your files to C:\Users\username\AppData\Roaming\app (or ...\Local\app). In Inno Setup that is {userappdata}\app (or {localappdata}\app). It Java, you can use System.getenv("APPDATA") (or System.getenv("LOCALAPPDATA")).
Anyway, to answer your question, you can use {%USERPROFILE}.
See also Inno Setup User Home Path.
Also in general, it's a bad idea to try to access a user profile in Inno Setup (un)installer, as the (un)installer can be executed using a different local account (typically Administrator), than the one you are interested in.
This is covered in Installing application for currently logged in user from Inno Setup installer running as Administrator.

Related

Java Spring project environment property file for both Linux and Window

I have a java spring project that contains property files. In the file, there are lots of folder path definitions. But these path are Linux paths. i.e. /home/share/Document. I would like to develop the project under both Linux and Windows so I have created a network share that I can access Linux file under Window environment. However, I have to add a prefix in front of the Linux path
such as \network\...\home\share\Document in order to make the path work.
What is the standard/normal way to handle this? I can image I should have two environment property files. For example, one is called DEV_unix.properties and the other is call DEV_win.properties. But this doesn't look perfect.
Could someone share his/her insights please ?
You can use profile in this case. Set active profile in your application.{profile}.properties. You can set this profile as a environment variable or VM arguments so that you need to set the environment variable in different machines based on the Operating system. You can check the below link for more details.
Springboot not loading application.dev.properties file

"Input file specified two times." error when using Cygwin sort on Windows

I'm building a desktop app that uses Cygwin to execute shell scripts on Windows 10. Ideally, users wouldn't have to install Cygwin because I'm putting the relevant exe files in my project. I have Cygwin's "sh.exe" in my project which I can call without an absolute path and it seems to be running grep, zcat, awk, etc with no issues.
It looks like I'm running into the issue explained in https://www.question-defense.com/2010/08/25/windows-7-cygwin-sort-input-file-specified-two-times where Window's cmd is using it's own sort rather than Cygwin's sort.exe and you have to put the path of the sort.exe in the script. So it looks like the user would have to download Cygwin which would somewhat defeats the purpose of my project because I want a hassle-free experience for users. I don't want them to have to download dependencies.
The only resolution I've thought of is to include the sort.exe in the project and replace the "sort" string in the script with the Windows path of the sort.exe, which I think would be in the directory where the user launched the app; maybe System.getProperty("user.dir").
Is there a better solution?
MobaXTerm seems to have got it down. They have a CygUtils plugin, which you have to download and put in the right place, but I imagine it wouldn't be hard for them to have their application come with CygUtils. I'm trying to do something like that.
I faced same issue while using Cygwin.
I renamed [cygwin64_folder]\bin\sort file to csort (or any other convenient name if you wish) and used csort command for my usage.

Java store config and other files

Currently i am storing a few config files and a history.xml file right next to my executable .exe.
However some users have reported that they have to run my program with Administrator rights, otherwise settings and history is not saved to these files.
Where should i save my config files and history.xml in order to not require my users to run the app with administrator rights?
Would be really nice with a solution that works on both Windows and OSX
Any ideas?
Your users are probably saving the files in a folder under Program Files or another 'protected' folder.
Either they should save it in a users-folder, or you should work with a full path to some path on the system, like 'C:/myapp/'.
You can use a helper function to check if you're using Windows or *Nix, and then depending on that return a certain path. I'm not close to my computer so can't test but this should work:
return System.getProperty("os.name").egualsIgnoreCase("Windows");
You can also make use of "user.home" for the users home directory (always writeable) and "file.separator" so you don't even need to check whether you're on Windows or not.

JAR executable doesn't start if it's in Programs directory

I'm into a very strange issue that's making me crazy .-.
I'm working on a relatively big Java project on Windows, using NetBeans and IzPack to prepare the graphical installation package.
Everything is ok, the compiled installer seems to work and my program is copied in 'C:\Programs\MyProject' folder.
But... when I double click on the myproject.jar in that folder it doesn't start at all. I obviously tried to open a prompt and type 'java -jar myproject.jar' but nothing, not even a line of error code.
The curious facts are two:
if I open it using the prompt with administration rights it works
in the same folder there is another jar, 'uninstaller.jar' created by izpack, and it works with double click.
I double checked my JVM installation, the PATH/JAVA_HOME/... values, and Properties->Security tab of my JAR but the permissions to execute/read/write for every kind of user are ok, and also are equal to the uninstaller.
So what's the problem? Thanks
This is almost certainly caused by Windows UAC on Vista and Windows 7.
Your program is probably trying to write to data files in the same directory as it is installed.
On Windows, well behaved programs write to the users or all users app data directory.
The location of that directory varies depending on the version of Windows.
You can use the system property "user.home" to find a safe place to store data.
You can also get a list of environment variables for shared and per user program data folders from here.

Can you determine if Vista UAC allows writing to a directory without elevation in java?

Here is the scenario. I have an application which writes a configuration file in its directory (user.dir). When the user cannot write to that directory due to UAC issues, I would like to change that to write to user.home/.appname/. The problem is that Windows really lies to my application and writes to user.dir which is in the Program Files directory, but although it allows the write and the read (even after restarts) it doesn't store it there, it stores it in a hidden directory (the home directory/AppData/Local/VirtualStore/Program Files/appname), making it hard/impossible for the user to find if they want to edit the file.
However, I don't want to just change my application to write to user.home and be done with it because some users run the application off of a USB drive, at which point I want to use user.dir if it is available, because it would not be helpful to leave things around the user home directory in that scenario (on a guest computer).
So after that rather long winded background, is there a way from java to know if the local directory is really truly directly writable from Java or if vista is going to instead virtualize the directory writes to another location?
This problem occurs if the Java executable is not marked as Vista compatible (using the manifest). The current release from Sun is marked as compatible. So the simplest solution is to use the latest release. This means that now neither files nor registry entries are virtualised.
Edit from author of OP:
Java 6 Update 10 (bug 6722527) added the manifest to the relevant files. Bug 6737858 addressed further issues, and is recorded as fixed in Release 12, although it is not in the release notes. For JDK 1.5, the installer was fixed in Update 11, however there will be no manifests added to the exe by Sun. You can add one yourself by putting the manifest file in the same directory as the exe if it is important enough.
After writing your file, can you just check that the file suddenly appeared in virtualized directory? I'd do a small "touch" file at app start to set a global boolean variable userUserHome.
Prepare a native EXE that loads the JVM in process (java.exe does this but you will need your own).
Add a manifest file (or in RC data) that specifies UAC as invoker.
Try writing to the folder to see if it works.
Or decide this is too much work and use a config file.

Categories