FGU Updater refuses to run when FGC is open

[kruvek]

Not sure if this would be considered a bug, but if I've got FGC open and running, the FGU updater states that Fantasy Grounds is open and that it can't update until it's closed.

Considering that FGU and FGC don't share data folders (and in fact, can't have the same data folder, if I remember correctly), not sure why the FGU updater should be worrying if FGC is running or not.

[pollux]

This has been reported before. Basically the FGU updater can't tell the difference between FGC and FGU because it's checking for a running executable with a given name and that name is the same in both products. I certainly consider it confusing and buggy behavior, but I think it's not near the top of the list of things to look at.

[Someone2345]

Unless you want msss users to use the application...
(Buttons not working will be the biggest reason people do not use the system (or be even bothered to test the system for you).

[Trenloe]

This is working as designed. There are issues with the FGU updater if FG Classic is running.

[pollux]

This is working as designed. There are issues with the FGU updater if FG Classic is running.

What are the issues? I don't have a link handy, but I recall Moon Wizard discussing this in another thread and my impression was that the issue was as simple as "the check to determine if FG is running doesn't distinguish between FGC and FGU because the binary names are the same". Given that they install to different program directories, and run from different data directories, I have trouble imagining what other conflicts could possibly occur. Maybe something in the registry, but again I can't think of any essential reason that registry keys should need to be shared. If they were appropriately named they COULD use non-conflicting registry keys and allow fully independent operation.

It's certainly operating as designed, but it's much less clear that the design is desirable or constrained by technical necessity. My impression was that it was more a concern of time and priorities at a time when a lot is going on.

[LordEntrails]

What are the issues? I don't have a link handy, but I recall Moon Wizard discussing this in another thread and my impression was that the issue was as simple as "the check to determine if FG is running doesn't distinguish between FGC and FGU because the binary names are the same". Given that they install to different program directories, and run from different data directories, I have trouble imagining what other conflicts could possibly occur. Maybe something in the registry, but again I can't think of any essential reason that registry keys should need to be shared. If they were appropriately named they COULD use non-conflicting registry keys and allow fully independent operation.

It's certainly operating as designed, but it's much less clear that the design is desirable or constrained by technical necessity. My impression was that it was more a concern of time and priorities at a time when a lot is going on.
The FGU Updater checks for a running process called fantasygrounds.exe. It would be a bad idea to update files that are currently in use, so if you are using FGU it doesn't let you update. Because FGU and FGC use the same process name, the FGU updater can not distinguish (as written) and it won't let you update.

Whether that was an oversight on design or has other limits, I can not imagine it is of very high importance to resolve or address at this point since it is so easily worked around and has minimal impact on use.

[pollux]

Whether that was an oversight on design or has other limits, I can not imagine it is of very high importance to resolve or address at this point since it is so easily worked around and has minimal impact on use.

I feel like it's reasonable for a new user to expect that separate programs should be able to run and update independently of each other, and as someone who pays a fair bit of attention to forum posts and experiments that illuminate FGC/FGU internal behaviors, I would be very surprised if there was a substantial technical issue that prevented concurrent updating. Those make me feel like the most accurate description, and also the most empathetic description for a confused new user is to call it a bug or a design oversight.

I largely agree with your assessment of relative importance in our current climate of connection and performance issues, but it's equally clear that people find this confusing. I recall at least 4 people reporting it or adding to conversations to note that this behavior confused them at one point. While it's true that the workaround isn't too bad once you know what to do... it's not at all obvious that you should need to close FGC to update FGU (unless you understand how FGU does process detection, which no user should have to know). A better goal is to avoid confusing behaviors in the first place, rather than accumulating sharp edges that non-technical users must debug and learn workarounds for.

[Trenloe]

If it’s been coded specifically to do the check because there have been issues before, then it’s not a bug. You can continue to debate whether it’s a design oversight, issue, not enough time to implement, whatever.

The devs have coded it this way and I’m sure if they're aware of why they did that (we can assume they are) and so they’ll be able to consider if it’s going to be possible to code it differently to ensure correct operation in future. I think we can leave it up to them.

[LordEntrails]

Taking a WAG, I suspect they used identical process names to facilitate fewer conflicts with anti-virus programs and getting programs whitelisted. But, you know what WAG stands for so give it as much value as that. As Trenloe says, it was a conscious decision and the devs are aware.

[pollux]

If it’s been coded specifically to do the check because there have been issues before, then it’s not a bug. You can continue to debate whether it’s a design oversight, issue, not enough time to implement, whatever.

The devs have coded it this way and I’m sure if they're aware of why they did that (we can assume they are) and so they’ll be able to consider if it’s going to be possible to code it differently to ensure correct operation in future. I think we can leave it up to them.

I don't think the devs did code it this way intentionally, they're aware of it NOW but it's not an intentional behavior. The sequence played out like this:


FGCUpdater needed a way to ensure that it didn't update FGC while FGC is running. The mechanism of this check is to query the running process list for a process named FantasyGrounds.exe.
The FGU filesystem layout is decided, and FGU is installed to C:\Program Files\SmiteWorks\Fantasy Grounds\ by default, with the main EXE being named FantasyGrounds.exe (which is the same as FGC).
FGUUpdater needs a way to ensure that it doesn't update FGU while FGU is running. The mechanism for this check is to query the running process list for a process named FantasyGrounds.exe (which is the same as FGC).
An unintended and unnecessary result emerges from the previous three intentional decisions. It's now impossible for either updater to update either program when either FGC or FGU is running. This property was never necessary for correct behavior, and was never a design goal. It's an undesirable emergent behavior that falls out of previous decisions which were each made in relative isolation.


The above contains a small amount of speculation around intent, but I believe that most of the facts of how the system behaves were confirmed by Moon in a separate thread.

We do of course need to leave the ultimate decisions about what to implement when to the devs, but it's valuable to let confused users know that they're not alone in their confusion, to remind everyone when issues are raised repeatedly, and... within reasonable limits... to speculate on the technical concerns that drive given decision to help users empathize with devs and summarize what is publicly known.

[damned]

I would go with your assessment that it is probably an unintended consequence. However I dont see an overly easy way to avoid it. I am sure there is probably some ways to do this but at the cost of development time that has already been allocated elsewhere.
When this happens to me I close FGC, start the FGU updater and then relaunch FGC.

[pollux]

I would go with your assessment that it is probably an unintended consequence. However I dont see an overly easy way to avoid it. I am sure there is probably some ways to do this but at the cost of development time that has already been allocated elsewhere.

Unfortunately the lowest cost time to address this issue was in step 2, when determining the FGU install layout. Had a different binary name been chosen, everything would have shaken out naturally. It's expensive to fix now, but many positive side-effects would emerge from having unambiguous naming conventions everywhere. I've stopped updating this list and I've seen half-a-dozen additional cases since, but I've documented this confusion elsewhere (https://www.fantasygrounds.com/forums/showthread.php?54661-FGU-recommendation&p=484223&viewfull=1#post484223).

But granting that the renaming fix does also cause different problems and isn't an obvious win at this late stage, it does seem that it might be straightforward to extract the PATH of the binary from the process list (https://stackoverflow.com/questions/5497064/how-to-get-the-full-path-of-running-process I haven't) as well. I have no personal experience with this, and there may be other factors involved... but the FG Updater must know the install path and so if the path is extractable from the running process in a few lines of code, that suggests that a relatively quick fix is available to allow each updater to use the path to determine whether it is FGC or FGU that is currently running.


When this happens to me I close FGC, start the FGU updater and then relaunch FGC.

I do understand the workaround, and I agree that it is simple to EXECUTE. But in order to execute the workaround, one first needs to UNDERSTAND it. The cost of gaining that understanding varies wildly from person to person. For you and I, it was probably no more than a few seconds of confusion... it may not even have registered consciously as confusion. But there have been non-technical users who had to post in the forums in order to discover the workaround, which means that it cost them a great deal more time to gain that understanding. And it likely happened at a time when their mind was already being stretched learning all the truly essential things they need to know in order to be successful with FGU.