= Storage =
	
== Files and data servers ==

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

    * The inputs and outputs of computation;
    * Components of application: executables, libraries, etc.
    * Data for its own sake, e.g. as part of a distributed storage system. 

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

Files are '''immutable'''. This means that all replicas of that file are assumed (and required) to be identical. If a file is changed, even by a single byte, it becomes a new file, and must be given a different name than the original.

== File properties ==

Files have various properties, including:

    * '''Physical name:''' unique identifier for the file. Must be nonempty, at most 255 chars, and may not contain '..' or '%'.
    * '''Sticky:''' don't delete file on client (see below).
    * '''Report on RPC:''' include a description of this file in scheduler requests.
    * '''Maximum size:''' if an output file exceeds its maximum size, the computation is aborted. 

File properties are specified in [XmlFormat#file_info XML elements] that appear, for example, in [WorkGeneration workunit templates].

== File references ==

The way a particular application uses a file is called a '''file reference'''.
File references have the following properties:

    * '''logical name''': the name by which the program will refer to the file.  BOINC provides a mechanism for mapping logical names to physical names, so that applications don't have to know the physical names of their input and output files.
    * '''copy file:''' use this if your application doesn't use BOINC's filename-mapping mechanism.
    * '''optional:''' Use this for output files, to indicate that the application doesn't always generate the file, and that its absence should not be treated as an error. 
    * '''no_validate''': Indicate that an output file should ignored during validation; i.e., two instances may be considered identical even if they have different values in this file.

File reference properties are specified in [XmlFormat#file_ref XML elements].

== File management ==

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

    * On the client, input files are deleted when no workunit refers to them, and output files are deleted when no result refers to them. Application-version files are deleted when they are referenced only from superseded application versions.
    * On the client, the 'sticky' flag overrides the above mechanisms and suppresses the deletion of the file. The file may deleted by an explicit [DeleteFile server request]. The file may also be deleted at any time by the core client in order to honor limits on disk-space usage.
    * On the server, the [FileDeleter file deleter daemon] deletes input and output files that are no longer needed. This can be suppressed setting the 'no_delete' property on the  file, or using command-line options to the file deleter.