| 22 | | * '''Physical name:''' unique identifier for the file. Must be nonempty, at most 255 chars, and may not contain '..', '/', or '%'. |
| 23 | | * '''Sticky:''' don't delete file on client (see below). |
| 24 | | * '''Report on RPC:''' include a description of this file in scheduler requests. |
| 25 | | * '''Maximum size:''' if an output file exceeds its maximum size, the computation is aborted. |
| | 22 | * '''Physical name:''' unique identifier for the file. |
| | 23 | Must be nonempty, at most 255 chars, and may not contain '..', '/', or '%'. |
| | 24 | * '''Sticky:''' don't delete file on client (see below). |
| | 25 | * '''Report on RPC:''' include a description of this file in scheduler requests. |
| | 26 | * '''Maximum size:''' if an output file exceeds its maximum size, the computation is aborted. |
| 34 | | * '''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. |
| 35 | | * '''copy file:''' use this if your application doesn't use BOINC's filename-mapping mechanism. |
| 36 | | * '''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. |
| 37 | | * '''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. This only affects the sample_bitwise_validator; not any custom validator you may have written. |
| | 34 | [[Image(http://boinc.berkeley.edu/files.png)]] |
| 39 | | File reference properties are specified in [XmlFormat#file_ref XML elements]. |
| | 36 | Each project has its own directory where all its file reside. |
| | 37 | The name of each file is its physical name. |
| | 38 | |
| | 39 | Each job executes in its own '''slot directory''' ({{{slots/0}}}, etc.). |
| | 40 | The slot directory contains links to the job's input and output files. |
| | 41 | The name of the link is a '''logical name'''. |
| | 42 | (These links aren't symbolic or hard links, because Windows doesn't have them; |
| | 43 | rather, they're XML files containing the path of the file in the project directory). |
| | 44 | Applications call a BOINC API function [BasicApi#filenames boinc_resolve_filename()] |
| | 45 | to map logical names to physical names prior to opening them. |
| | 46 | |
| | 47 | This architecture provides two advantages: |
| | 48 | |
| | 49 | * Multiple concurrent jobs can access a given file without having separate copies of it. |
| | 50 | * Applications can contain hardwired (logical) file names, but can be run against different physical files. |
| | 51 | |
| | 52 | The way a job uses a file is called a '''file reference''', |
| | 53 | and is specified in [WorkGeneration job input and output templates]. |
| | 54 | A file reference includes the logical name. |
| | 55 | It can also specify a '''copy file''' attribute; |
| | 56 | if present, the linking mechanism described above is not used; |
| | 57 | rather, the BOINC client copies the file from the project directory to |
| | 58 | the slot directory before running the application (for input files) |
| | 59 | or copies the file from the slot directory to the project directory |
| | 60 | after running the application (for output files). |
| | 61 | This mechanism is needed for |
| | 62 | [WrapperApp legacy applications] |
| | 63 | that don't use BOINC's API functions. |
