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