Github issue #1388 describes a situation where a wrapper can't exec
an executable file because there's an open file descriptor to it.
This happens only if the file is > 10 MB so that async copy is used.
The reason for this (which Rom identified) is as follows.
Suppose several such tasks start around the same time.
The first async copy finishes and the wrapper is started by fork/exec.
The process inherits open fds for all the other copies.
When they finish and are started, they won't be able to exec.
The fix is to use boinc_fopen() instead of fopen() in ASYNC_COPY.
The former sets its fd to close-on-exec.
In general the client should always use boinc_fopen() instead of fopen();
in addition to close-on-exec, it also does retry.
I changed a couple of other fopen()s also.
This was presumably the cause of the recent Einstein@home problem.
- client: set file ownership and permissions after an async copy.
- client: set file ownership and permissions after a
regular (non-async) copy.
The latter 2 bugs would affect a VM app that copies
its executable to slot/x/shared
svn path=/trunk/boinc/; revision=25468
- client: add <async_file_debug> log flag
- client: do decompress (both sync and async) to a temp file,
then rename
- client: if a file's status is VERIFY_PENDING on startup,
set it to NOT_PRESENT; that will trigger a verify
- client: do async copy only if size is above threshold
svn path=/trunk/boinc/; revision=25222
When a large file is copied from a project dir to a slot dir,
it's copied in chunks,
interleaved with other polling activities such as GUI RPCs.
That way the manager doesn't freeze while large copies
(e.g. VM images) are happening
svn path=/trunk/boinc/; revision=25192
Christian Beer