Hello,
In my example_app project, the sample_bitwise_validator keeps failing. Specifically the file path is incorrect, the magic hex number dir used by the validator in the upload dir for a fopen is wrong. Also the file name is incorrect, its added an extra underscore. Anyone else have these issues?

Heres the log:
2016-11-30 09:47:31.9131 [WU#1 example_app_1479628780_0] handle_wu(): No canonical result yet
md5_file: can't open /home/boincadm/projects/uppercase/upload/9f/example_app_1479628780_0_0__0md5_file: No such file or directory2016-11-30 09:47:31.9143 [CRITICAL] [RESULT#1 example_app_1479628780_0_0] md5_file() failed for /home/boincadm/projects/uppercase/upload/9f/example_app_1479628780_0_0__0: fopen() failed2016-11-30 09:47:31.9143 [CRITICAL] check_set: init_result([RESULT#1 example_app_1479628780_0_0]) failed: fopen() failed2016-11-30 09:47:31.9146 [RESULT#1 example_app_1479628780_0_0] Invalid [HOST#1]
2016-11-30 09:47:31.9146 [HOST#1 AV#7] [outlier=0] Updating HAV in DB. pfc.n=0.000000->0.000000

Have the same issue with my real resarch app.

The trivial validator is working fine.

I'm using the AWS AMI.

Cheers
Seth

OK so I figured the magic hex dir is calculated via a has on the path name.

you can check the has for a file name using bin/dir_hier_path

So it remains my problem is the file name that it is hashing when trying to validate has an extra "_" in it and gives the wrong hash. Question is why?

In my example the file searched by the validator is example_app_1479628780_0_0__0. It should be example_app_1479628780_0_0_0

Hi, are you using the latest version of the code from github? At one point there was a problem with the new random filename extension of result files. This should be fixed now.

The trivial validator is working because it doesn't do any file path lookups.

Btw: there is no official BOINC AWS AMI, the last tim I checked there was only an AMI that contained the Client not the server.

Hi Christian,
Thanks for your prompt response. It may be that the AMI I am using is not the latest version of the code. I will check that out when I get back to the project over the weekend.

BTW the AMI approach is suggested here: https://boinc.berkeley.edu/trac/wiki/CloudServer

Although there is no AMI version specified and it implicitly implies Caveat Emptor! Theres' been a couple of other gotchas with it but in general it has been very useful to get something going quickly.

I'll let you know via this thread how I go.

Cheers
Seth

Hi,
FYI a fresh build of BOINC server in Virtual Box yielded a better validator and assimilator. They both seemed to have bugs in the AMI version.

May I suggest if the AMI is no longer being supported then the link is removed?

Cheers
Seth

I don't think that the wiki page with the AMI link claims that it is always up to date. From a technical perspective it can't be. It's the responsibility of the user to keep systems up to date. The link you mentioned also contains an email to the user who created this and may be available to support this.