On 02.08.12 15:07, Bernd Machenschalk wrote: > On 02.08.12 09:51, Bernd Machenschalk wrote: >> On 25.07.12 14:49, [email protected] wrote: >> >>> Have the validator mark the files as read only as the first step in what it >>> does.
Implemented (in our own validator only so far). There is one case where this behavior worries me a bit: While tasks are in progress, a Client's BOINC data directory is backed up somewhere. The Client finishes the tasks, uploads and reports them. Validation is performed. Assume that the validation is inconclusive. The result files stay in the upload directory on the server, but locked (read-only). Then, for some reason, the backup is restored. The Client finishes the same tasks again, but can't successfully upload the result files as long as the old ones are there, which may be for weeks or even months. How would the Client react on tasks that can not be uploaded for several weeks? A possible relief would be in the validator to mark the result file writable again in case of an inconclusive validation, but I'm still thinking whether this may cause other problems. Also, too, the file_upload_handler uses "advisory locks" to lock files that are currently uploaded. I'm not sure whether and how the validator should be made aware of this, e.g. avoid validating (and mark read-only) files that are currently locked. And in addition int the case that originally pointed me to this problem, the locking apparently didn't prevent the Client from doing seven uploads in a single second (we're not using FCGI, so it could hardly be the same instance). Well, admittedly, this happened on an NFS filesystem, where locking may not work reliably. Best, Bernd _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
