Update_Core, again

[Roland140]

The thing that confuses me is that it downloads the WU with no problem then can't download the cores. That tells me that the download of the core file isn't actually done by F@Hclient but another process that's contained in the WU.

The files weren't from a different machine, just a clone of this same machine at an earlier date when F@H was working properly. I'm just wondering what will happen when a core, other than 21, is needed.

[bruce]

Are you still running two firewall programs? Disable each one individually and then concentrate on that one.

[Roland140]

No, only running Norton. Later today I'll be comparing settings on the desktop with this craptop where F@H works. I'm hoping to find something there, but don't expect to, if that makes sense.

[bruce]

I suppose this could be a file permissions problem. Did you create the directories in the file tree or was the done automatically by FAHClient? (If FAHClient cannot open all the direcores or it cannot create files where it wants them to be, you might get that (misleading) message.

[Roland140]

Thanks again, Bruce, for working on this with me.

I created the cores directory tree only, everything else was created by F@H. That tells me that F@H, at least the client.exe, has permission to create/write folders there. Which makes me wonder what the process name, .exe., is writing the cores directory structure and files.

In the mean time, this kluge fix has the machine back up at ~1.5 million points per day. No more vacuuming up my non-existent hair off the desk for now anyway.

[bruce]

In Windows, FAHClient.exe runs as a semi-hidden process and it runs as your primary user. All the directories should be in a hidden file structure %APPDATA% and should belong to you. In Linux, a secondary userid is created which runs FAHClient as a legitimate service and all directories should belong to that user.

In the discussion above, you were NOT running FAHClient in %APPDATA%\fahclient but rather in Program files, which does not have write permissions for your primary user.

[bruce]

The following demonstrates that I do not have write permission in \Program files (or in \Program files (x86) on Windows 7 or greater)

Code: Select all

C:\Users\bruce>cd \Program files

C:\Program Files>dir t*
 Volume in drive C has no label.
 Volume Serial Number is 64B8-596D

 Directory of C:\Program Files

File Not Found

C:\Program Files>mkdir temp
Access is denied.

The following demonstrates that I DO have write access to %APPDATA%\FAHClient

Code: Select all

C:\cd %APPDATA%\fahclient

C:\Users\bruce\AppData\Roaming\FAHClient> dir t*
 Volume in drive C has no label.
 Volume Serial Number is 64B8-596D

 Directory of C:\Users\bruce\AppData\Roaming\FAHClient

10/26/2017  09:23 AM    <DIR>          themes
               0 File(s)              0 bytes

C:\Users\bruce\AppData\Roaming\FAHClient>mkdir temp

C:\Users\bruce\AppData\Roaming\FAHClient>dir t*
 Volume in drive C has no label.
 Volume Serial Number is 64B8-596D

 Directory of C:\Users\bruce\AppData\Roaming\FAHClient

03/27/2019  04:09 PM    <DIR>          temp
10/26/2017  09:23 AM    <DIR>          themes
               0 File(s)              0 bytes

[Roland140]

The F@H client obviously has all the permissions it needs to write to either Program Files or AppData, otherwise it wouldn't have been able to install itself. My question remains regarding what process actually writes the core data though.

[bruce]

The function of an installer is to acquire the necessary permissions to write to Program Files and to put the programs there. Once the install has been completed, you shouldn't have write permissions there. FAHClient is NOT an installer and it shouldn't be able to create working files there. One malware exploit used to be have the evil program create a data file which actually contains executable code and then sneakily find a way to execute that data. Microsoft has blocked that exploit and FAHClient is designed to accept that limitation.

[Roland140]

So the client is responsible for writing the core directory and files in the appdata directory. Since it successfully wrote everything else, and continues to write logs and new work units, I can't see how it would be blocked from writing the core files.

[bruce]

The problem is not that it cannot write the core files. The problem is that your firewall is blocking FAHClient from performing the download from the server and uncompressing them correctly. The download requires BOTH internet permissions and file permissions.

[Roland140]

If the client can download the work unit I can't see how it can't download the core files.

[foldy]

One difference between work units and core files is they come from different servers and the core files are executables.

[bruce]

Unfortunately the temporary fix than you found for this problem is not a permanent solution. You need to continue to debug the issue. A couple times a year FAH will release either a new FAHCore or will release an update for an existing one. By that time, you'll have forgotten it's still broken.

* PAUSE (or FINISH) the active WU(s) that is/are using a specific FAHCore.
* Delete (or rename) the applicable FAHCore
* Start folding again ... which will force FAHClient to download a fresh copy of the FAHCore to replace the missing one.
* If it succeeds, great. If not, disable various parts of your security software and try again ... until it succeeds.
* Then adjust the settings of that particular security component until it works.