boinc/doc/files.php

<?
require_once("docutil.php");
page_head("Storage");
echo "
<h3>Files and data servers</h3> 
<p>
The BOINC storage model is based on <b>files</b>.
The inputs and outputs of applications,
and the application executables, are files.
<p>
The BOINC core client transfers files to and from <b>data servers</b>
operated by the project, using HTTP.
<p>
A file is described by an XML element of the form 
<pre>
&lt;file_info>
    &lt;name>foobar&lt;/name>
    &lt;url>http://a.b.c/foobar&lt;/url>
    &lt;url>http://x.y.z/foobar&lt;/url>
    ...
    &lt;md5_cksum>123123123123&lt;/md5_cksum>
    &lt;nbytes>134423&lt;/nbytes>
    &lt;max_nbytes>200000&lt;/max_nbytes>
    &lt;status>1&lt;/status>
    [ &lt;generated_locally/> ]
    [ &lt;executable/> ]
    [ &lt;upload_when_present/> ]
    [ &lt;sticky/> ]
    [ &lt;signature_required/> ]
&lt;/file_info>
</pre>
The components are as follows: 
<ul>
<li> The <b>&lt;name></b> element gives the file's name, which
must be unique within the project.
<li> Each <b>&lt;url></b> element gives a URL where the file is
(or will be) located on a data server.
<li> The <b>&lt;md5_cksum></b> element is the MD5 checksum of the file.
<li> The <b>&lt;nbytes></b> element is the size of the file in
bytes (may be greater than 2^32).
<li> The <b>&lt;max_nbytes></b> element is the maximum allowable
size of the file in bytes (may be greater than 2^32).
This is used to prevent flooding data servers with bogus data.
<li> The <b>&lt;status></b> element is 0 if the file is not present,
1 if the file is present, or a negative error code if there was a
problem in downloading or generating the file.
<li> The <b>&lt;generated_locally></b> element, if present,
indicates that the file will be generated by an application on
the client, as opposed to being downloaded.
<li> The <b>&lt;executable></b> element, if present, indicates
that the file protections should be set to allow execution.
<li> The <b>&lt;upload_when_present></b> element, if present,
indicates that the file should be uploaded after it is created.
<li> The <b>&lt;sticky></b> element, if present, indicates that
the file should be retained on the client after its initial use.
<li> The <b>&lt;signature_required></b> element, if present,
indicates that the file should be verified with an RSA signature.
This generally only applies to executable files.
</ul>
These attributes allow the specification of various types of files: for
example, input or output files that are retained for use as input to
later computations.
<p>
Once a file is created (on a data server or a participant host) it
is immutable.
<h3>File references</h3> 
<p>
Files may be associated with <a href=work.html>workunits</a>,
<a href=result.html>results</a> and
<a href=app.html>application versions</a>.
Each such association is represented by an XML element of the form 
<pre>
&lt;file_ref>
    &lt;file_name>foobar&lt;/file_name>
    [ &lt;open_name>input&lt;/open_name> ]
    [ &lt;main_program/> ]
&lt;/file_ref>
</pre>
The components are as follows: 
<ul>
<li> The <b>&lt;file_name></b> element specifies a file.
<li> The <b>&lt;open_name></b> element is the name by
which the application will refer to the file.
<li> The <b>&lt;main_program/></b> element is used for files
associated with application versions.
It indicates that this file is the application's main program.
</ul>
";
page_tail();
?>