Beta 4.2.0: Updater somehow corrupts itself (on Mac)

Hi,

When switching between the TEST and LIVE instances on my Mac, it appears the updater somehow corrupts the "FantasyGroundsUpdater" app and as a result, after launching FGU and clicking on the "Update" button, FGU exits, but the updater never launches. The actual update program "FGUpdaterEngine" is still functional and I can launch that by hand and perform an update manually, but it appears when clicking on the "Update" button FGU tries to run the intermediate app "FantasyGroundsUpdater" and it fails. If I try to launch it by hand I get this message:

Attachment 52683

The program appears to be present in my filesystem, but something about it is not liked by my Mac.

To recover so the "Update" button works again in FGU, I have to re-download the FGU install from the web site. Simply switching back to LIVE does NOT update the updater back into a working state. Re-downloading from the web site appears to be only way to get it working again. But, if I then try to test the beta, it breaks again.

I didn't think I had seen this issue initially on Tuesday when I was toggling between the beta and Live version. I'm pretty sure it started happening with the later update on Wednesday.

Cheers,
Brian

I'm not sure what might be causing that, since the version of the FantasyGroundsUpdater.app appears to be correctly signed/notarized from our source control and patch system installs for both Live and Test. Also, I just updated back and forth on my Catalina machine without issue between the two channels.

I wonder if Apple had an update that changed permissions in some way over the last week; and maybe only on some platforms (M1 vs. Intel chips; Catalina vs. Monterey; etc.)

Regards,
JPG

I poked around a bit more and figured why it stops working, but I don't know what specifically causes it, other than switching to the test version. The FantasyGroundsUpdater.app/Contents/MacOS/FantasyGroundsUpdater binary is not executable. If I do a "chmod a+x" of it, then it all works again without me having to re-download everything from the website. I can click on the "Update" button within FGU and it launches the updater as expected.

However, if I switch to the TEST instance via the settings and choose update, the FantasyGroundsUpdater loses the execute permissions again. It ends up looking like this:

-rw-r--r-- 1 mosttornbrain admin 5734208 May 6 21:01 FantasyGroundsUpdater

Something about switching to the test instance causes the loss of the execute permissions.
I am running Monterey, 12.3.1.

Cheers,
Brian

Some more details that might be helpful. I noticed in the Smiteworks/FantasyGrounds application folder there is a FantasyGroundsUpdater.log file. It contains the following:

Code:

---

didFinishLaunching.
CurDir: /Applications/SmiteWorks/Fantasy Grounds/FantasyGroundsUpdater.app/Contents/MonoBundle/
START RunUpdater()
AppDelegate:RunUpdater
CheckNewUpdater(): /Applications/SmiteWorks/Fantasy Grounds/FantasyGroundsUpdater_NEW True
New Updater Valid: True
Recursive Delete: /Applications/SmiteWorks/Fantasy Grounds/FGUpdaterEngine
Deleting parent /Applications/SmiteWorks/Fantasy Grounds/FGUpdaterEngine
RecursiveCopy: /Applications/SmiteWorks/Fantasy Grounds/FantasyGroundsUpdater_NEW - /Applications/SmiteWorks/Fantasy Grounds
CONTINUE LAUNCH: True
Check path: /Applications/SmiteWorks/Fantasy Grounds/FGUpdaterEngine/FGUpdaterEngine.app exists: True
UpdateExecutePermissions
Standard input chmod
LaunchApp()
FGUpdaterEngine Process Started.

---

Note the line three from the end about "Standard input chmod". Now, if I run the FantasyGroundsUpdater by hand in a terminal window, I get all of the same log entries, however there is a curious addition of an error message (I'm assuming it goes to stderr, which is perhaps why it didn't show up in the log file):

Code:

---

/Applications/SmiteWorks/Fantasy\ Grounds/FantasyGroundsUpdater.app/Contents/MacOS/FantasyGroundsUpdater ; exit;
didFinishLaunching
didFinishLaunching.
CurDir: /Applications/SmiteWorks/Fantasy Grounds/FantasyGroundsUpdater.app/Contents/MonoBundle/
START RunUpdater()
AppDelegate:RunUpdater
CheckNewUpdater(): /Applications/SmiteWorks/Fantasy Grounds/FantasyGroundsUpdater_NEW True
New Updater Valid: True
Recursive Delete: /Applications/SmiteWorks/Fantasy Grounds/FGUpdaterEngine
Deleting parent /Applications/SmiteWorks/Fantasy Grounds/FGUpdaterEngine
RecursiveCopy: /Applications/SmiteWorks/Fantasy Grounds/FantasyGroundsUpdater_NEW - /Applications/SmiteWorks/Fantasy Grounds
CONTINUE LAUNCH: True
Check path: /Applications/SmiteWorks/Fantasy Grounds/FGUpdaterEngine/FGUpdaterEngine.app exists: True
UpdateExecutePermissions
Standard input chmod
/bin/bash: line 1: chmod: command not found
LaunchApp()
FGUpdaterEngine Process Started.

---

Specifically, the concern is "/bin/bash: line 1: chmod: command not found". If I copy this text from terminal into a text editor, it appears the "chmod" is actually prefixed with something possibly being a unicode character? It looks to be <U+FEFF>. Not sure if that is significant or a red herring.

Perhaps the updater is attempting to do a chmod of the newly updated FantasyGroundsUpdater, but there's some extra unicode encoding in front of the chmod so it isn't recognized properly as a valid shell command?

Just spitballing ideas here. Let me know if there is anything else that might be helpful to try to get to root cause for this.

Cheers,
Brian

Thanks for the additional information.

The odd thing in this situation is that the version of the FantasyGroundsUpdater.app executable has not been updated in almost 9 months; and both the Test/Live builds are using the same version of the executable.

Also, on both my Mac and on our tester's Mac, we are not seeing that issue. I think we are both running Catalina (since we only have two Macs internally for build and testing). I don't know if that's the difference, but seems weird that characters would be inserted just based on OS version difference.

Regards,
JPG

I didn't write this code personally; but here's what's in the file for that section. I'm not seeing anything that looks incorrect, or any special characters in the code. I even opened in a text editor that allows viewing of all hidden characters, but there are no hidden characters in the code (just tab/CR/LF around the code as expected).

Code:

---

        static void UpdateExecutePermissions()
        {
            Log("UpdateExecutePermissions");
            ProcessStartInfo proc = new ProcessStartInfo("/bin/bash");
            proc.WorkingDirectory = AppDirectory();
            proc.UseShellExecute = false;
            proc.RedirectStandardInput = true;
            proc.RedirectStandardOutput = true;

            Process p = new Process();
            p.StartInfo = proc;
            p.Start();
            Log("Standard input chmod ");
            p.StandardInput.WriteLine("chmod -R 777 FantasyGroundsUpdater.app");
            p.StandardInput.WriteLine("chmod -R 777 FGUpdaterEngine/FGUpdaterEngine.app");
            p.StandardInput.WriteLine("chown -R $(whoami) FantasyGroundsUpdater.app");
            p.StandardInput.WriteLine("chown -R $(whoami) FGUpdaterEngine/FGUpdaterEngine.app");
            //p.StandardInput.WriteLine("exit");
            p.StandardInput.Flush();
            System.Threading.Thread.Sleep(500);
        }

---

Regards,
JPG

Just a guess, but it looks like the <U+FEFF> you're seeing is a byte order mark, and from your log it appears it's only before the first chmod command (at the start of the input stream to the process). Though, I'm not sure what might cause that to be written, maybe some encoding related setting in your environment?

Quote:

---

Originally Posted by Ecks

Just a guess, but it looks like the <U+FEFF> you're seeing is a byte order mark, and from your log it appears it's only before the first chmod command (at the start of the input stream to the process). Though, I'm not sure what might cause that to be written, maybe some encoding related setting in your environment?

---

That is a good observation that only the first chmod fails. That would lead to pointing to that stray UTF character already in the output buffer before the script contents are written. I wonder if writing a blank "CR/LF" before that first chmod might fix it. I have confirmed by manually changing the file permissions of FGUpdaterEngine/FGUpdaterEngine.app that they do get changed back to 777 after the script runs. So, it appears it is indeed just the first chmod that is failing.

I have also confirmed that the missing chmod error doesn't show up in the FantasyGroundsUpdater.log file because it is sent to STDERR. If I run FantasyGroundsUpdater via the following command line, the error does show up in the log file:

Code:

---

./FantasyGroundsUpdater > mylog 2>&1

---

As another test, I have reverted back to the original version of the FGU installer from the web, and just running the FantasyGroundsUpdater provided in the web install (v4.1.0 (2021-05-27)) the chmod error occurs. So... this problem has likely been lurking for a while - at least for macOS Monterey, and it reveals itself only when a new copy of the FantasyGroundsUpdater.app is fetched and it doesn't arrive already with an execute bit set.

Cheers,
Brian

This might be a wild stretch, but it looks like someone else has run into what appears to be similar issue with Unity and StandardInput.Writeline() doing something odd with extra character encoding: https://forum.unity.com/threads/c-st...solved.410154/

Not sure if the code in question for the FantastyGroundsUpdater is using the same library or not, but thought it would be worth mentioning.

Cheers,
Brian

One more update - hopefully this is a helpful observation. If I change my terminal default encoding from "en_US.UTF-8" (which I believe is the macOS default) to "en_US.US-ASCII" then the problem with the first chmod failing goes away when I run FantasyGroundsUpdater by hand. However, it still appears to fail behind the scenes when switch from TEST back to LIVE FGU. Changing the terminal app default encoding doesn't affect the updater when it is launched by FGU.

Cheers,
Brian