Whenever dCache decides to copy a file from disk to tertiary storage a user-provided executable which can be either a script or a binary is automatically started on the pool where the file is located. That executable is expected to write the file into the Backend Storage System and to return a URI, uniquely identifying the file within that storage system. The format of the URI as well as the arguments to the executable, are described later in this document. The unique part of the URI can either be provided by the storage element, in return of the STORE FILE operation, or can be taken from dCache. A non-error return code from the executable lets dCache assume that the file has been successfully stored and, depending on the properties of the file, dCache can decide to remove the disk copy if space is running short on that pool. On a non-zero return from the executable, the file doesn’t change its state and the operation is retried or an error flag is set on the file, depending on the error return code from the executable.

If dCache needs to restore a file to disk the same executable is launched with a different set of arguments, including the URI, provided when the file was written to tape. It is in the responsibility of the executable to fetch the file back from tape based on the provided URI and to return 0 if the FETCH FILE operation was successful or non-zero otherwise. In case of a failure the pool retries the operation or dCache decides to fetch the file from tape using a different pool.