Bug Updating .EXE causes all prefs to be lost

Alium

Member
See title. Can reproduce by installing the exe and running mafia app. Then change any pref to a non-default value. Install a different version and your pref will be back to default.

My friend prefers using the .exe over the .jar and he is who tipped me off to this issue. I was able to recreate on my machine as well. We both have Windows.

His workaround is to make a copy of all folders/files in the mafia folder, update, then copy them back.
 

gausie

D̰͕̝͚̤̥̙̐̇̑͗̒e͍͔͎͈͔ͥ̉̔̅́̈l̠̪̜͓̲ͧ̍̈́͛v̻̾ͤe͗̃ͥ̐̊ͬp̔͒ͪ
Staff member
I defer triage to a Windows user :)
 

fronobulax

Developer
Staff member
I don't use the exe. I just replace the jar file in the "mafia tree".

It sounds like the installation aspects of using the exe create "new" KoLmafia files and directories. Since you can reproduce the issue could you install, change a preference, note some timestamps and install and check timestamps. If "installing via the exe" is creating a new set of files and directories then we at least know where to look.
 

Alium

Member
It seems like a new set of files and directories are being created. Gives a fresh install every time.

Exe installed and app ran. When app runs, various folders are created.
1659105179888.png

Different .exe version installed
1659105209220.png
 

heeheehee

Developer
Staff member
Apparently there's a --win-upgrade-uuid option we could specify to jpackage. Oracle's docs are very sparse about what exactly that does.

What we probably ought to do is make settings / scripts on Windows also install to special user directories, rather than the current directory (and maybe set up shortcuts to those special directories as part of the install).
 

MCroft

Developer
Staff member
I don’t think I was around when it was decided that the default for Windows would be to put the user’s data in the application folder, which is different from the default for Linux or Mac.

I wonder if the app should use the path flag for an appropriate user space folder. We don’t have to change the default for the jar (presumably there’s some reason for commingling app and data), but the installer may be making assumptions that are different from the choices we made long ago.
 

fronobulax

Developer
Staff member
I do not recall being involved with building the exe and git blame suggests @heeheehee would know more than I do.

The model for separating executable items from data is different on Windows and the other supported OSes, or at least it was when key mafia decisions were made :) The historical solution to not comingle data and executable required Administrator access at installation time which was not desirable for mafia.

As a Windows mafia user I expect my data to be in a subdirectory tree that contains the mafia jar at the root. Other configurations are possible but they (used to?) require changes in how things are run or the environment which, in turn, may require Administrator access. We know that if this subdirectory exists on a Windows Desktop then there are likely to be file permissions that prevent mafia from writing files. There are other locations where mafia has failed because of write permissions.

A very long time ago when I had to configure a Windows MSI there were distinct paths for a new install and an update. A new install expected the target location to be empty and created what it needed. An update usually offered an option to keep the old settings and there would be files and directories that would only be created if they did not exist. My gut feel is that if we could successfully tell our builder that it should be expecting to update a preexisting installation that would solve this problem.
 

MCroft

Developer
Staff member
I do not recall being involved with building the exe and git blame suggests @heeheehee would know more than I do.

The model for separating executable items from data is different on Windows and the other supported OSes, or at least it was when key mafia decisions were made :) The historical solution to not comingle data and executable required Administrator access at installation time which was not desirable for mafia.

As a Windows mafia user I expect my data to be in a subdirectory tree that contains the mafia jar at the root. Other configurations are possible but they (used to?) require changes in how things are run or the environment which, in turn, may require Administrator access. We know that if this subdirectory exists on a Windows Desktop then there are likely to be file permissions that prevent mafia from writing files. There are other locations where mafia has failed because of write permissions.
That seems to be based on mafia practice, not the platform. It has a historic basis and I wouldn't want to change it for people who are currently using mafia the way mafia has always worked.

It's not common for other Windows applications to commingle data and code, is it? Surely this is the point of the user folder and the various subfolders.

That said, the executable model is not the same as the mafia jar (which is a few folders deep inside the executable package). It doesn't seem to be built the same expectations as we did many years ago (which is not a surprise) and if we could provide an environment-based solution for users who want to use the executable it would not delete their user data.

In the end, I'd like it to work well for Windows users, because I want it to be successful. If we can change the windows installer, that's one solution. If we can change the way the app launches via the .EXE (and only via the .EXE), that would also solve the problem.
 

heeheehee

Developer
Staff member
That seems to be based on mafia practice, not the platform. It has a historic basis and I wouldn't want to change it for people who are currently using mafia the way mafia has always worked.
Right, which is why I suggested adding shortcuts, which would look mostly the same to an end-user. I don't know how easy that is.

If we can change the windows installer, that's one solution. If we can change the way the app launches via the .EXE (and only via the .EXE), that would also solve the problem.
Note that we explicitly specify -DuseCWDasRoot=true for the Windows installer. Without it, we currently default to System.getProperty("user.dir"), which is basically the same thing, although we could ostensibly construct a subdirectory of user.home as we do for other OSes. If I were to make this change, I'd prefer to lock it behind some other command-line flag.

Now, if setting --win-upgrade-uuid to a consistent hardcoded value is sufficient to fix this issue, that's great. I suspect it's not. I'm surprised that the installer outright deletes other files in the target directory (yet doesn't outright delete the directory, based on the timestamps of app/ and runtime/).

If frono doesn't beat me to the punch, I might tinker with this a bit more later this weekend.
 

fronobulax

Developer
Staff member
If frono doesn't beat me to the punch, I might tinker with this a bit more later this weekend.

I'm poking at it. I'm trying to build an exe locally. I've been using gradlew jpackage and am getting failures. The first was I had to install a Wix package. Now I get two issues. One is that

Task ':jpackage' is not up-to-date because:
Task has not declared any outputs despite executing actions.

and the other is that

java.nio.file.FileAlreadyExistsException: <deleted>Temp\jdk.jpackage328853867287251609\images\win-msi.image\KoLmafia\app

which is at the moment confusing.
 

Alium

Member
How is this going? I'm not familiar with how the exe is built but happy to help poke at this if given some direction.
 

fronobulax

Developer
Staff member
Sorry. I can't build locally and got distracted by something else. You have my undivided attention until the next shiny object.
 

fronobulax

Developer
Staff member
Code:
C:\KoLmafia>jpackage --type exe --name KoLmafia --app-version 22.08.26665 --main-class net.sourceforge.kolmafia.KoLmafia --main-jar KoLmafia-26665.jar --java-options -DuseCWDasROOT=true --dest C:\KoLmafia\build\releases --icon C:\KoLmafia\util\windows\KoLmafia.ico --input C:\KoLmafia\dist --win-shortcut

I do all my gradle tasks from C:\KoLmafia. The above command line hopefully builds a windows exe with the same parameters as gradle. It fails the same way gradlew jpackage fails, with a java.nio.file.FileAlreadyExistsException exception for a temp file that is no longer on the system after the command fails.

This is sort of a reference post so I remember the issue is jpackage.

I note that jpackage will only build what is native for the system it is running on so anyone trying to build and debug will need to be on Windows.

My java is

java 17 2021-09-14 LTS
Java(TM) SE Runtime Environment (build 17+35-LTS-2724)
Java HotSpot(TM) 64-Bit Server VM (build 17+35-LTS-2724, mixed mode, sharing)

Still trying to avoid shiny obj... Oh Look! A squirrel!!!
 

fronobulax

Developer
Staff member
I can't build an exe on my machine. I can extract the parameters gradle is passing to jpackage. I then run package from a command line and always get java.nio.file.FileAlreadyExistsException. I've tried not using all of the parameters, (i.e. make the default package and not force an exe) changing where the temp directory is and running as a Windows Administrator. Searches make me think jpackage once had some problems with java.nio.file.FileAlreadyExistsException but none of the work-arounds seem to apply and I'm supposedly running a fixed version.

@fewyn @heeheehee Any ideas? Something is able to successfully build a windows exe and I'm stuck until I can replicate that environment or figure out what my environment is, or is not, doing.

Thanks.
 

MCroft

Developer
Staff member
Have you tried 17.0.4, it's a bit newer than the java you're seeing in your CLI entry.

Have you tried to see if the verbose flag tells you what file already exists?
 

fronobulax

Developer
Staff member
Have you tried 17.0.4, it's a bit newer than the java you're seeing in your CLI entry.

Have you tried to see if the verbose flag tells you what file already exists?

Didn't know I wasn't on the latest. Will check.

jpackage doesn't seem to have any verbosity options.

I can reproduce the problem without gradle.

By the time jpackage exits the file is no longer present. Monitoring a directory in real time via the GUI is fraught with uncertainty but I can't find any evidence that the file was ever created or existed. The same techniques do allow me to watch files being created and deleted as tests are run :)
 

fronobulax

Developer
Staff member
java 17.0.4.1 2022-08-18 LTS
Java(TM) SE Runtime Environment (build 17.0.4.1+1-LTS-2)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing)

No change, either from gradle or jpackage directly.
 
Top