Disk operations


The ability to perform disk operations (e.g. creating files) is part of the functionality offered by most existing programming languages. The Sphere Engine service allows you to perform disk operations within an isolated workspace dedicated for a single submission.

Workspace

Regardless of the environment in which the program is executed, disk operations require appropriate permissions. Execution environment used by the Sphere Engine service provides a workspace for the submission inside which it has the appropriate permissions.

The workspace has the following properties:

  • temporariness – the workspace is created at the beginning of processing the submission and destroyed after its completion; it means, among other things, that the created files are not available after the submission has been executed,
  • isolation – the workspace is not available for other submissions,
  • clean start – the workspace is empty at the start of processing the submission.

From the technical standpoint, the workspace is a directory on the hard drive. Due to the isolation feature, the access path to the workspace is generated randomly and made available to the submission via the environment variable named WORKSPACE.

The environment variable WORKSPACE contains the absolute path to the directory in which it is possible to perform disk operations. A sample path might look like this: /tmp/52981b4e-f464-4a6e-baa8-976287248de0.

Important: Disk operations in the Sphere Engine service are possible in any programming language that allows for:

  • reading data from environment variables,
  • performing disk operations.

Features of the workspace

The program's permissions inside the workspace allow for:

  • manipulating directories
    • creating
    • deleting
    • moving
    • renaming
  • manipulating files
    • creating
    • deleting
    • moving
    • reading
    • modifying name
    • modifying content
  • manipulating file and directory permissions
  • retrieving information (e.g. regarding the size) about files and directories

An example of a submission that works with data on a disk

The following program written in PHP retrieves the workspace path, then creates a directory named test, where it then creates a text.txt file.

<?php

// retrieve workspace absolute path from environment variable
$workspacePath = getenv('WORKSPACE');

$testDirectoryPath = $workspacePath . '/test';
$testFilePath = $testDirectoryPath . '/test.txt';

// create directory of the name "test"
mkdir($testDirectoryPath);

// create a file "test.txt" in the "test" directory
// the content of the file is "test file content"
file_put_contents($testFilePath, 'test file content');

Disk operations in programming problems

The workspace is shared by all components activated for the purpose of verifying the correctness of the submission, i.e.:

  • the user's program (for each test case),
  • the test case judge (for each test case),
  • the master judge.

Before executing the user's program for the first test case, the workspace is empty (in accordance with the clean start property). During subsequent runs of the program or judges (for the next test cases as part of processing the same submission), the workspace contains all files and catalogues that have been created so far.

Please bear in mind that test cases are executed successively. The exact order of execution is as follows:

  1. user's program (test case #1)
  2. test case judge (test case #1)
  3. user's program (test case #2)
  4. test case judge (test case #2)
    (…)
  1. master judge

Allowing for the use of disk operations by the user's program (as well as by the judging programs) extends the possibilities offered by programming problems on the Sphere Engine platform. For example, it is possible to:

  • verify the ability to manipulate files and directories from the level of the program,
  • transfer information between test cases,
  • create problems that require performing many operations, the results of which are saved in separate files,
  • create problems in which subsequent test cases require the use of data generated in earlier test cases (see example below).

Example:

Let us consider a problem that requires executing certain operations on data saved in the CSV format. In the first test case, the initial data will be provided which should then be converted to a normalized form (e.g. present all decimal numbers in the data using a period (i.e., the "." character) to separate the fractional part). The normalized data should be saved in the workspace as a file called data_normalized.csv.

The second test case is based on the file that was created before. The purpose of the test case is to filter data according to a certain criterion. The resulting data should also be saved in the workspace, this time in a file named data_filtered.csv.

The purpose of the last test case is to calculate statistics for the data in the previously created file. The generated statistics should be saved in the workspace in a file named summary.dat.