The backup and restore depends on copying files when required. During a normal phone usage, a range of servers and applications have files open to read or write. If a file is locked, it cannot be copied. This section describes file locks for public and private data, and for different applications.
For platform security, directories are divided into public and private areas. Public files can be viewed and altered by any application (although file locks may still get in the way). However, processes can define private data areas where they store files that only they can operate on. The system also defines some areas as private to store executables and read-only data.
Files locks are handled in applications when the Backup Engine signals the start or completion of a backup or restore. Different types of applications handle file locks differently.
Files in the public area of the filing system can be backed up and restored directly by the Backup Engine but this requires all other processes to free up file locks when required.
Ownership of public data files is more complex than private data files. Platform Security requires a process (application or server - basically a private data owner) to specify the private files to be backed up. There is a close association of private files with specific applications. It is possible to associate public files with specific applications, but more than one data owner may own a public file or a public data file may not have a data owner.
Note: The Backup Engine can list the public files of a data owner, but does not back up or restore them. Backing up public files is handled in the Backup Server by a device creator.
A backup operation needs to read files so processes must hand over exclusive-locks on files but can retain read-locks. In practice, many processes release all locks for the sake of safety and simplicity. In order to perform a backup operation, applications and servers must flush any pending updates to files and allow all the files to be read. Cached data can be retained and backup does not alter data files. After the backup, servers and applications can re-take file locks and carry on.
A restore operation requires exclusive access to files so processes must release all locks on files. In order for a restore operation to take place, applications and servers must discard all cached data and allow files to be written or overwritten. When the restore has taken place, servers and applications must reload their data from files that can be expected to have changed.
As a principle, the backup process attempts to protect private data in the following ways:
Application executables are only backed up with the consent of the developer. This means that if a developer forgets about application backup, the application is not backed up.
Private data is only backed up with the consent of the data owner. This means that if a developer does not enable a data owner to back up its private data, the data is not exposed.
Private data can be encrypted before delivery to the backup client (normally a PC). The backup process supports encryption, but a device creator must include a specific mechanism to provide the encryption key. Phone users are usually able to access the key, and this may not be a good way to protect the data.
By default, all GUI applications are terminated when a backup or restore operation takes place. When applications exit, system servers release file locks. The server exit code is implemented within the Uikon subsystem. This mechanism avoids GUI application developers having to implement backup-aware code in most cases.
A GUI application usually does not need to perform backup or restore. If a GUI application is not set as a system process, it will be terminated when file locks are required and will be re-started after the backup or restore. The terminate-restart behavior ensures that direct and (most) indirect file locks are free. A potential optimization for a GUI application is to store the current view and state when terminated and to adopt the same view when it restarts. This makes for a seamless restart after a backup. The application appears the same to the user, as if it had not terminated and restarted.
Some servers access files only when they receive calls from clients. If clients terminate (GUI applications) or drop connections, their server then releases locks on files. Application developers do not need to take further actions.
However, application developers must be aware of the sequence of actions during a backup or restore. Some behaviors, which appear to be performance optimizations, may prevent a successful backup:
The backup and restore functionality is blocked if the file is not closed. For example, the server can keep a file open, even when all the clients have closed the file. This is done so as to improve the performance, wherein a client requires the file to be opened again.
Restore operation may be corrupted, if a server keeps the cached data of the same file that is re-opened.
If such optimizations are required, the server must become backup-aware and release file locks promptly and flush data caches on backup and restore.
The servers and applications need to be backup-aware:
If they do not terminate during a backup or restore operation.
If they do not release file lock owing to the behavior of the client.
If a process is not liable to external events during backup and restore, it simply needs to react to backup and restore events and release file locks. If a process can receive external events during a backup or restore such as a telephone call, an incoming message or an external request for some action, the process needs to ensure that the event does not interfere with any files during the backup or restore. Examples of possible interference include:
Writing to call log files when a telephone call is received
Storing an incoming message in the messaging store
Applying an incoming configuration message.
The process application developers handle the particular event and few of them are listed below:
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights
reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License
v1.0.