Files and data servers

The BOINC storage model is based on files. Examples of files:

The BOINC core client transfers files to and from project-operated data servers using HTTP.

A file is described by an XML element of the form ".html_text(" foobar http://a.b.c/foobar http://x.y.z/foobar ... 123123123123 134423 200000 1 [ ] [ ] [ ] [ ] [ ] [ ] [ ] ")." The elements are as follows: "; list_start(); list_item( "name", "The file's name, which must be unique within the project. If you want to use participant hosts on which filenames are case-insensitive (e.g. Windows) this uniqueness is case-insensitive." ); list_item("url", "a URL where the file is (or will be) located on a data server." ); list_item("md5_cksum", "The MD5 checksum of the file." ); list_item("nbytes", "the size of the file in bytes (may be greater than 2^32)." ); list_item("max_nbytes", "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." ); list_item("status", "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." ); list_item("generated_locally", "If present, indicates that the file will be generated by an application on the client, as opposed to being downloaded." ); list_item("executable", "If present, indicates that the file protections should be set to allow execution." ); list_item("upload_when_present", "If present, indicates that the file should be uploaded when the application finishes. The file is uploaded even if the application doesn't finish successfully. API functions are available for uploading files prior to finishing computation. "); list_item("sticky", "If present, indicates that the file should be retained on the client after its initial use." ); list_item("signature_required", "If present, indicates that the file should be verified with an RSA signature. This generally only applies to executable files." ); list_item("no_delete", "If present for an input (workunit) file, indicates that the file should NOT be removed from the data server's download directory when the workunit is completed. Use this if a particular input file or files are used by more than one workunit, or will be used by future workunits." ); list_item("no_delete", "If present for an output (result) file, indicates that the file should NOT be removed from the data server's upload directory when the corresponding workunit is completed. Use with caution - this may cause your upload directory to overflow." ); list_item("report_on_rpc", "Include a description of this file in scheduler RPC requests, so that the scheduler may send appropriate work using locality scheduling." ); list_end(); echo "

Once a file is created (on a data server or a participant host) it is immutable. This means that all replicas of that file are assumed to be identical.

File references

Files may be associated with workunits, results and application versions. Each such association is represented by an XML element of the form ".html_text(" foobar [ input ] [ ] ")." The elements are as follows: "; list_start(); list_item("file_name", "Specifies a file."); list_item("open_name", "The name by which the application will refer to the file. Applications access files using the following functions: 

        char physical_name[256];
        boinc_resolve_filename(\"input\", physical_name, 256);
        fopen(physical_name, \"r\")
In this example, open_name is 'input'. It is mapped, at runtime, to a path that includes the filename ('foobar' in the example above). "); list_item("main_program", "Relevant only for files associated with application versions. It indicates that this file is the application's main program. "); list_end(); echo "

File management

BOINC's default behavior is to delete files around when they aren't needed any more. Specifically:

"; page_tail(); ?>