The content-based file management system used by Condor GAHP
used a file's MD5 hash as its physical name.
This caused problems for Einstein@home because their app
expected filenames with particular extensions.
So I:
- changed the docs and param names of the C++ interface
to the file management system (query_files() and upload_files())
to clarify that the physical file names can include additional text
besides the MD5 hash.
- changed the BOINC GAHP to look for filename extensions,
and append these to the physical filenames
Since most everyone is running something more recent that BOINC 7.2.16, we can assume that the hardware just does not support hardware acceleration. Inform BOINC that the VM Extensions have been disabled so that the server can either assign a 32-bit VM which can use software emulation, or just not assign future work to the host.
Report the MD5 signature in the stderr output as well so that duplicate screen shots can be quickly identified. Of course this assumes that the exact same PNG is generated across different machine types and video cards. Currently I believe that it should given the hardware in question is virtualized.
It isn't clear that this is causing the startup failure of VM(s) on MacOS X, but it is unsightly to see in the error log.
See:
https://github.com/BOINC/boinc/issues/1526
Creates a file "etc\fstab" which allows BOINC XML soft links to properly refer to files in the project directory if using an application compiled with a cygwin environment on a Windows host.
Original author: Bernd Machenschalk.
The macro substitution needs the APP_INIT_DATA aid object to be populated. This is only the case after boinc_init_options() and boinc_get_init_data() but the parsing of the job.xml happens before that. This commit moves the substitution step after the aid object is populated with the project directory.
The job file needs to contain
<rename_output>
<filename>foo</filename>
</rename_output>
In the output template the logical name of that output file must be specified as "foo.link"
After completion, the file "foo" will be renamed/moved to the result file in teh project directory
Basically the VM periodically 'touches' the file to let the wrapper know that it is still alive. If the wrapper does not detect a change to the mod time of the file at the specified interval it assumes the worst and aborts the job.
Requested by CMS.
David Anderson