Persistent File Storage

Java DTV applications have access to the file system accessible through the java.io.File API, java.net.URL with the "file:" protocol, and javax.microedition.io APIs if present.

Note that the persistence of a file is guaranteed over the run time of the application that created the file. When the given application terminates, the file may be subject to removal i.e. in the case of storage shortage. It also means that a given file MUST NOT be removed as long as the application that created that file is running whether that file and its corresponding handle is still opened or not.

The file hierarchy is structured to simplify access to the application files.

• A single root of the file system for to all applications must be defined by the implementation. For the Java DTV runtime, the root is accessible via the property "com.sun.dtv.persistent.root" available from java.lang.System.getProperty.
• Access to any files above this root directory MUST result in a Security violation, in the case of the Java DTV runtime in a java.lang.SecurityException.
• For each organization, for which there is an application, a subdirectory of the root directory is defined using the organization id formatted as a hexadecimal string using only digits and lowercase characters ('0'..'9','a'..'f'). The string MUST NOT have any leading '0' characters.
• For each application, a subdirectory of the organization directory is defined using the application id formatted as a hexadecimal string using only digits and lowercase characters ('0'..'9','a'..'f'). The string MUST NOT have any leading '0' characters.
• For each application, the "current directory" set to the application directory when the application is started. The current directory is changed only by the application.
• Directories are created automatically as follows:
  • For the organization below the root and application directory below the organization directory. For example, <root>/<organization_id>/<application_id>/
  • For directories in the path referred to by any authenticated credential in the Per Application Policy down to a wildcard ("*" or "-").
  • Before or during the first access to the directory or any file in the directory.
  • The owner of directories created below an application directory MUST be the same as the owner of the application's directory so that the owner always has access to its own directories and contained files. The owner MUST be the 48-bit concatenated organization and application id.
  • The group of directories created below an organization directory MUST be the same as the group of the organization's directory so that the applications with the same organization can share access their group directories and contained files depending on the group access rights.
  • The owner of the organization directory MUST be the platform.
  • When created the owner access rights MUST grant read, write, and lookup access to the owner.
  • When created the group access rights MUST NOT grant read, write, or lookup access to other members of the group or to any other application. The application can change the rights as necessary.
  • In the unusual situation when a directory below the application directory is not owned by the application that directory MUST be deleted and recreated as an empty directory with the application as owner.
• Each signed and authenticated application that requests file access in the Per Application Policy MUST be given access:

  Path	Owner Access	Group Access	World Access
  <root>/*	read	read	read
  <root>/<organization_id>/*	read/write	read	-
  <root>/<organization_id>/<application_id>/*	read/write	-	-