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.
At some point MS introduced a Microsoft Extension mode to fopen called 'commit mode'. This additional mode disables the OS buffers. So when on Windows force stderr redirection to use commit mode.
See:
https://msdn.microsoft.com/en-us/library/yeby3zcb.aspx
Apparently, on Win, there is still a write lock on stderr.txt,
and its buffer isn't flushed, until shortly after the app process exits.
This is bizarre, but so be it.
If a job has an output file with <copy_file> and <optional>,
and it doesn't create the file,
then the call to boinc_rename() (to move it to the project dir) fails,
and we back off and retry.
Solution: in boinc_rename(), if the rename fails,
check if the file exists, and if it doesn't then don't retry.
Also:
- when writing client messages, use the actual current time
(dtime()) rather than client_state.now.
- write log msgs when output file renames fail
Previously, the dir_scan() function didn't distinguish between
- reaching the end of the directory
- errors
It just returned nonzero in either case.
This means that the function that cleans out a slot dir
(client_clean_out_dir())
could potentially return success even though the directory is nonempty.
This could potentially cause the recently-reported problem
where a slot dir contains a VM image from a previous job.
There were two problems:
1) we were sorting before parsing the client state file
(which is where we get project names from)
2) the Win implementation of strcasecmp() wasn't right;
it returned difference but not order.
If set, non-CPU-intensive jobs are exempted from mass suspend
(e.g. suspend CPU, time of day, CPU throttling).
You can still suspend them individually.
There was a bug where, when you suspend GPU activity,
GPU jobs show as suspended but are not actually suspended.
This was because of recent changes to distinguish GPU and non-GPU coprocs.
Change things so that coprocs are by default GPUs.
If you want to declare a non-GPU coproc in your cc_config.xml,
you much put <non_gpu/> in its <coproc> element.
On Android, the way we were getting os_version
(Linux version + Android version)
didn't work because get_host_info() was getting called before every
scheduler RPC, and it overwrote the Android version part.
Solution: divide host info into dynamic (disk usage, network info)
and static (everything else).
Computer the static part only at startup.
Also factor the Unix HOST_INFO code into multiple functions.
The following should apply to GPUs but not other coprocs (e.g. miner ASICs):
- "suspend GPUs" command in GUI
- prefs for suspending GPUs
- always removing app from memory when suspended
There's no need for this since the bodies are stored in CDATA.
Doing so causes a bug:
if a notice body contains an entity (like &)
and we get the same notice from an RSS feed,
the 2 notices are treated as separate
since the old copy is unescaped and the new one isn't.
This leads to confusion;
e.g. if you do "read config files" it will look for cc_config.xml
in the new directory, not find it, and set default options.
Also, log files end up in old directory.
Also, gui_rpc_auth.cfg will be in new directory,
and the Manager won't look there.
- get_project_config.php: if project supports LDAP,
advertise this to the client.
- Manager: if project supports LDAP, say "Email address or LDAP ID"
in Attach Project wizard,
and don't do email address validation.
- lookup_account GUI RPC (client side): if passing an LDAP ID,
don't lowercase it, and don't hash passwd
- lookup_account GUI RPC (server side): if passing an LDAP ID,
pass appropriate URL args to Web RPC
- lookup_account Web RPC: in LDAP case, pass "ldap_auth" arg,
and pass "ldap_uid" and "passwd".
Handle these appropriately.
David Anderson