I'm testing out Install4J 5.1.5 and am running into a little issue. My original jar file I would like to distribute has full permissions-- anyone can open it (with something like 7zip)-- and modify/delete any entries in that jar. However this same jar-- when installed by install4j-- the permissions become essentially read-only. I can't modify/delete anything in the jar after installation-- gives me permissions issue.
The reason why I want to modify/delete is that there are a few properties files in the jar that get defined by the user during installation so I want to modify / delete whats already in there with the user's new files...
The only thing I can think of is that I set the default unix file and directory modes to 777. But this doesn't seem to work. Any ideas?
The installer has a helper process that runs with elevated permissions. This helper process is started by the "Request privileges" action that is by default added to the "Startup" node of the installer.
All actions whose "Action elevation type" property is set to "Elevate to maximum available privileges" are executed in the helper process.
If you want to modify the file in your application (i.e. not in the installer), you can use a "Add Windows file rights" action to make the file writable for everybody.
Related
Is it possible to change the permissions of files that get added to the DMG volume created by install4j (via Media->macOS single bundle archive->Installer options->DMG options and files->Additional Files in DMG->"+"-> Regular file)?
I am adding a separately uninstall.app (to uninstall pre-install4j versions of the Application) but the added executable file the uninstall.app runs ends up not being executable! (I have to add all of the files under uninstall.app individually)
I have a workaround which is to include the uninstall.app as a separate File set which gets embedded within the Application.app/Contents/Resources/app folder, and then creating a symbolic link in the DMG down to that, but I'd prefer to have the whole uninstall.app separated -- it can be run directly from the DMG.
Suggestion: Allow setting permissions of the additional files (or just preserve permissions). Also a recursive "copy folder into DMG" would be good, or alternatively allow copying of an already defined File set into the DMG?
Thanks for your suggestions, I have added them to our issue tracker.
Unfortunately, it is not possible to change the permissions as of install4j 8.0.
Update 2021-02-05
This will be available in install4j 9.0.
I'm hosting an AppImage file on github releases
https://github.com/Gilad-Kutiel-App/jumpfm/releases.
The file does not have an execution permission when downloaded and it is needed to set it manually.
Is there anything I can do about it ?
Thank you,
Gilad
Before you can run an AppImage (or really any executable for that matter), you need to make it executable. This is a Linux security feature. There are three main ways to make an AppImage executable:
1. With the GUI
Open your file manager and browse to the location of the AppImage
Right-click on the AppImage and click the ‘Properties’ entry
Switch to the Permissions tab and
Click the ‘Allow executing file as program’ checkbox if you are using a Nautilus-based file manager (Files, Nemo, Caja), or click the ‘Is executable’ checkbox if you are using Dolphin, or change the ‘Execute’ drop down list to ‘Anyone’ if you are using PCManFM
Close the dialog
Double-click on the AppImage file to run
2. On the command line
chmod a+x Some.Appimage
3. Automatically with the optional appimaged daemon
If you would like to have all AppImages be executable automatically, you can install the optional appimaged daemon. It will automatically add downloaded AppImages to the menu and make them executable for you. It can be downloaded from https://github.com/AppImage/AppImageKit/releases or installed from your distribution.
On your download page, you can link to the image and/or to http://discourse.appimage.org/t/how-to-make-an-appimage-executable/80
Note: Please DO NOT put an AppImage into another archive like a .zip or .tar.gz. While it may be tempting to avoid users having to set permission, this breaks desktop integration with the optional `appimaged daemon, among other things. Besides, the beauty of the AppImage format is that you never need to unpack anything
Is there a good technical or other reason why the MS hard-coded the Documents folder as the default location for WindowsPowerShell? MS has been criticized for too much configuration over convention in the past (WCF?), but a case can be made for more configuration in PowerShell. I, and I presume most developers, like to keep their development work centralized in a separate folder or volume away from personal and system files.
For instance, if you install PoshGit, it will install itself in C:\Users\Your Name\WindowsPowerShell\Modules. I don't want it to install itself there but in my own development partition d:\Dev\PowerShellScripts. There's no environment variable that controls this location.
Is there a reason for this or I just don't get it?
Can you explain yourself a bit more.
According to my understanding PowerShell.exe interpreter base directory is the one defined by $env:HOMEDRIVE, $env:HOMEPATH, that can be change using the user profile.
As shown in the screen shots here under :
Edited :
Ok, the screenshot comes from the user property in Active Directory MMC, you've got a simplest one in your windows seven user properties. But this has nothing to do with your problem.
Your problem is around the module installation. The think that you have to know is that Modules can be installed quite everywhere (even on a shared directory with some tricks). By default the environnement variable $env:PSModulePath points to the paths where Get-Module -ListAvailable look for them. So you can add d:\Dev\PowerShellScripts\Modules in this path and then copy the subfolder of C:\Users\Your Name\WindowsPowerShell\Modules created by PoshGit inside your Modules directory and it should work. Modules as opposite to Snapins don't need to be registered.
Now the reason why PoshGit choose to put module in user profile, raser than let you choose the place is PoshGit installer problem.
For more explanations read about Modules and about_environment_variables.
I have a Java rich client desktop app. that I want to distribute on some computers at work, but I've never done something like this before. People aren't too computer-savy at my workplace and since it is a student job, I won't be there for much longer and I'd like it if I could make my program easy to run by making it runnable when people double-click on it.
I also don't want to have to manually install a JRE to have it run. Basically, what I'd like to know is how to make my java application runnable easily by double-clicking (even if it's only on windows, it's okay). I'm pretty sure I'm going to need to package the correct JRE version alongside, but I don't know what's the correct way of doing this.
I read on some sites that you should not package a JRE along with your program because it makes people have multiple different versions, some of which are outdated, and it causes security issues, but this is not a problem in this case since the computers that are going to run my application are not connected to the internet and are only used to run this program anyway.
Somewhat related question: Since my application is currently an Eclipse project, I get my resources such as icons, images, SQLite database (for read and write), etc. using relative paths (e.g.: img/test.png).
Am I going to have to change any of those paths to have them keep working even while packaged?
What you're looking for is a JAR file. In eclipse, it's quite easy to make a Jar file. Specifically, you'll want to right click on your project, go to Export, and then select "Runnable Jar." Be careful with paths to folders. You may need to keep a resources folder next to the Jar file. You may need to provide some more specifics to get an exact answer on that. Typically, a Resources folder is located in the same spot as the JAR file (in the same folder on your computer).
A better option for easy install of a Java app. with a GUI is to launch it using Java Web Start. For the user, JWS is the 'one click' installation option that can (install & launch the app. then) add desktop shortcuts and menu items. A JWS launch would mean some more work for you, but it is a breeze for the end user.
To ensure a suitable JRE is present to run the app., use deployJava.js (see the JWS link for more details). The script would need to be reconfigured to get the JRE installer from your local network - the default is to get it from Oracle.
Most of the resources should be packaged in Jar files and supplied along with the app., but for the DB, use the JNLP ExtensionInstallerService to call the DB installer.
..Java Web Start is kind of a link (or I can make it a shortcut on the desktop) that the users will click to either install the JRE and run the program if the JRE isn't installed, or just run the program if the JRE is present on the computer.
The way it would work is to have a web page on the local intranet. When the user visits the page, the script checks for a suitable JRE.
If it is present, it writes the link to the launch file.
If there is no JRE, or the version is too low, it will guide the user through installing it (just a matter of them clicking 'OK' when prompted). Then it will put the link to the app.
I can then configure the link to grab the JRE from the server on our network.
That's the part where you need to reconfigure the script. AFAIR the script exposes an URL at which to look for JREs - that can be changed to point to a place on the intranet.
..So "Web" is only just in the name, the computers don't have to be connected to the internet to have this work, right?
Yes. JWS is a great launch technology for Java rich clients, but is a poorly chosen name.
To make the problem run by double clicking it you can distribute it as a jar file or a batch file to call the jar file.
For the installation part you can make a batch file that checks if java is present and then call the installer if it isn't.
Edit:
The batch code:
IF DEFINED JAVA GOTO ok
java-installer.exe
GOTO end
:ok
your-application.jar
:end
If you are finding it tough to implement the above mentioned methods. You can proceed with this simple approach.
Create a folder lib at a location. Place all the jars that your application uses into this. If you are able to create a jar for your application, you can very well place your application.jar into the lib folder too. Create a batch file at the same location that will contain the java command for your main class in it. The text within your batch might look something similiar to this :
set path="\lib\"
java -cp %path% package1.package2.MainClass
If you have any other dependencies, for ex: if you use images in your code under img/icon.jpg. Then you just have to shift the img folder to this location too.
Just zip these files using winrar and share it across. Running the batch file after extracting the zip would launch your java MainClass irrespective of the location in which it is placed in the client system.
PS : If you are unable to create a jar for your application and placing it in lib folder, just copy your bin folder with class files and paste it in the location and change the batch file accordingly to look for classes inside bin.
I installed Eclipse and am having some trouble relating to denied user permissions.
I am working on Vista inside a Windows domain. My user account is very restricted. My boss needs to grant administrator permission any time I install any application or establish a new network connection through the firewall.
Here are some of the problems that have occurred:
At Eclipse startup, Vista asks every time if I really want to run it. It doesn't remember my decision.
Eclipse doesn't remember my default workspace.
I installed the BIRT plugin. After a second restart it doesn't work anymore. The BIRT perspective does not run fine.
What permissions do I need to run Eclipse on Windows?
This problem occurs when you host the Eclipse application within a directory that is protected by the Vista or Windows 7 operating system. For example, %ProgramFiles%, %ProgramFiles(x86)%, or %ProgramW6432%. Unfortunately, for all of Eclipse's maturity, it still doesn't entirely restrict its per-user activities to the Windows operating system's user space.
If you don't care where your Eclipse application resides, or you don't have admin rights on your system, try moving the Eclipse application to a directory that is not protected by the Windows operating system.
If you have admin rights on your system, and want your Eclipse application to be hosted in one of Window's protected directories, you must make the directory writable to users. This will allow the proper operation of the Eclipse application, but be warned that it will also allow users to directly modify files within the Eclipse application directory. You can reduce this risk by making the directory writable to only the specific accounts that you choose.
Note that by performing either of the above solutions, it will not be necessary to run the Eclipse application with the "Run as Administrator" option.
To make the Eclipse application directory writable by users:
Right click on the Eclipse application directory within Windows Explorer.
Select "Properties".
Click the "Security" tab.
Click the "Edit..." button to change security permissions for the Eclipse folder.
If you want only specific user accounts to be able to write to the Eclipse application directory, click the "Add..." button to allow those accounts to appear within the "Group or user names" list.
One at a time, select each account to be granted write access to the Eclipse application directory, and then click the checkbox for "Modify / Allow" such that the checkbox is checked.
Conversely, if you want to allow all system users to be able to use Eclipse properly, select the "Users (YourComputerName\Users)" group from the "Group or user names" list, and then click the checkbox for "Modify / Allow" such that the checkbox is checked.
After all appropriate users have been given write access to the Eclipse application directory, click "OK". You should now be able to run Eclipse without issue.
tharkun's answer is sort of correct but I just wanted to post a "more correct" answer for anyone else who finds this question in the future.
For some reason, Eclipse needs administrator privileges in Windows 7 and Windows Vista machines. To do this one time, right-click the Eclipse executable or shortcut and click "Run as administrator"; to make it permanent, go to properties, the compatibility tab, and check the "Run this program as an administrator" box.
Despite tharkun's post, perhaps he forgot, Eclipse doesn't have an installer; you simply unzip it. There is no reinstallation necessary. If you run Eclipse normally and find something wrong, and just discovered this answer, you can safely run Eclipse as administrator from now on and nothing will be broken as a result of you not having run as administrator up until this point.
The problems with Eclipse that require administrator mode do not show up immediately, but for example if you check for updates with Eclipse running in non-administrator mode, Eclipse will claim that there are no update sites available. Also some GUI features will have problems.
These problems are likely caused by some of the advanced UAC features meant to protect your system, such as UAC Virtualization. Eclipse can (and hopefully will) be fixed to write only to user space and "play nice" with other Windows applications, but for now we have to simply run it as administrator and trust that it's not taking advantage of the added privileges.
As a sidenote, I just spent several hours trying to figure out how to get Eclipse to write inside the %AppData% directory, in hopes that it would solve this problem and allow Eclipse to be run in user mode, but I could not get Eclipse to honor anything I tried. Oh well...
eclipse require write permission to app folder
it has to be in a folder with user write permission, f.e. %localappdata%\Eclipse. if u place it in %programfiles%\Eclipse it can't write to config files or plugins
the app has no installer. it stores config files in the app folder by default. the official install path is "c:\eclipse" and they forgot to mention that write permission is required
https://wiki.eclipse.org/Eclipse/Installation
Decompress this file into the directory of your choice (e.g. "c:\eclipse" on Windows) and ensure you have full Read and Execute permissions.