| Home · All Classes · Annotated · Functions |
Qtopia identifies storage locations through the Storage.conf configuration file.
Devices are mapped to human-readable names using the Storage.conf configuration file. The file will also indicate whether or not a given device is removable or not.
For example:
[/dev/hda1]
Name = Internal Storage
Removable = 0
The device can be anything that appears in the first column of /etc/mtab, for example, //server/path/to/nfsmount is a valid device.
Storage.conf refers to devices but Qtopia uses path names and mtab is consulted to determine which device a given path is on. There is special case code for $HOME and the non-removable storage location should be located at $HOME. By removing the special case status of $HOME the requirement to have only one non-removable location is removed.
Storage.conf must:
For example:
[Translation]
File=QtopiaDefaults
Context=Storage
[HOME]
Name[] = HOME Storage
Removable = 0
Applications = 0
Documents = 1
Options = rw
[/dev/hda2]
Name[] = Program Storage
Removable = 0
Applications = 1
Documents = 0
[/dev/cf]
Name[] = CF card
Removable = 1
Applications = 0
Documents = 1
[/dev/loop1]
Name[] = Virtual CF
Removable = 1
Applications = 1
Documents = 1
The real system this Storage.conf represents could be as follows:
| Path | Device | Info |
|---|---|---|
| / | /dev/hda1 | jffs2 root (easy upgrades) |
| /home/root | HOME | This is on /dev/hda1 but it is treated separately |
| /progfs | /dev/hda2 | Applications are placed here - separated from the base system |
| /mnt/cf | /dev/cf | CF card (no applicationss for security reasons) |
| /mnt/vcf | /dev/loop1 | The loop back image that is pretending to be a CF card for testing purposes. |
The allowable parameters are:
The HOME location defaults to rw for its Options value. Qtopia assumes a location is writable only if Options contains rw. A location's Options might need to be overwritten if they don't include rw but are writable. For example, SMB mounts on a machine have Options of 0 or if they are overly complex cardInfoString() and installLocationsString() encode the Options as part of a ; delimited string.
The StorageInfo::filesytems() function provide filtering functionality.
For example, to extend the Documents file systems use the following:
FileSystemFilter fsf;
fsf.documents == FileSystemFilter::Set;
QList<FileSystem*> filesystems = storage->filesystems( &fsf );
The FileSystemFilter is then easily extended as follows:
class WriteableFileSystemFilter : public FileSystemFilter
{
public:
WriteableFileSystemFilter()
: writable( Either )
{
}
bool filter( FileSystem *fs )
{
if ( (writable == Set && !fs->isWritable()) ||
(writable == NotSet && fs->isWritable()) )
return false;
return FileSystemFilter::filter();
}
FileSystemFilter::FilterOption writable;
};
This is a simple example however more complex rules can be incorporated. So, putting it all together:
Application data is stored in the non-removable location, however documents can be stored in any location. Removable locations are re-scanned on insertion and removal.
Note: Users of commercial and evaluation version of Qtopia are encouraged to contact support for the latest information on this topic.
The scanning is triggered when the Qtopia library receives one of the following messages via the QPE/Card QCOP channel:
If QPE_SYSTEM_SYSFILEMONITOR is defined, Qtopia assumes that the surrounding system generates these messages, for example, by using the qcop command in the system HotPlug scripts. Otherwise, Qtopia polls every few seconds (wasting CPU).
Using read-only file systems have a number of benefitsa:
| Copyright © 2006 Trolltech | Trademarks | Qtopia 4.1.7 |