Otherwise, result file names can be inferred from result names.
An attacker with task A could find the name of the "wingman" task B,
upload fake files as B's output files,
upload the same files as A's output files,
report A as completed, and get unearned credit.
Projects that have there own assimilator need to implement the assimilate_handler_usage() function and should printf() a description of those custom options. For examples see sample_assimilator.cpp or script_assimilator.cpp
The assimilator handler can now pass unknown arguments to the project specific handler.
Projects that have there own assimilators need to implement the assimilate_handler_init() function and handle project specific arguments there. For examples see sample_assimilator.cpp or script_assimilator.cpp
I also added some checks for missing arguments and clarified some error messages.
The SETI@home result table is about to run out of 32-bit IDs,
so we need to move to 64-bit result IDs.
This will happen to the workunit table at some point too.
I changed the server C++ code to use the "long" type for all DB IDs
(and to use appropriate conversion codes like %lu).
"long" is 64 bit on 64-bit machines.
For uniformity I did this for all tables,
even ones (like app) that will never get big.
I chose NOT to change the DB schema for now.
The new code will work with 32-bit ID fields in the DB.
As projects approach the 32-bit limit on a table they can change
its ID field, and fields that reference this table, to BIGINT.
This is likely to happen only on the result and workunit tables.
I put functions in html/ops/db_update.php
to change the IDs of these tables.
- Fix various #include issues.
CODING STYLE LAW (minimal inclusion principle):
If foo.cpp requires <blah.h>,
#include <blah.h> in foo.cpp, NOT foo.h
svn path=/trunk/boinc/; revision=25837
- client (Unix): if client crashes while benchmark processes are going,
make sure they detect this and exit.
- back-end programs: remove hardwired assumptions about
what directory they run in, and hence where config.xml is.
E.g., daemons look for it in "..", others expect it in current dir.
New approach: all the programs look for the project dir as follows:
1) the environment var BOINC_PROJECT_DIR, if defined
2) the current dir, if config.xml is there.
3) else ".."
This means you can run programs in either proj/bin/ or proj/,
or (using BOINC_PROJECT_DIR) you can keep executables
outside of the project dir.
svn path=/trunk/boinc/; revision=18042
Christian Beer