Home · All Classes · Annotated · Functions

Document Storage

Qtopia identifies storage locations through the Storage.conf configuration file.

Storage.conf

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.

What do we want Storage.conf to do?

Storage.conf must:

  1. Identify the various locations that exist on the device.
  2. Indicate if a given area allows documents and/or applications to be placed there.

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:

PathDeviceInfo
//dev/hda1jffs2 root (easy upgrades)
/home/rootHOMEThis is on /dev/hda1 but it is treated separately
/progfs/dev/hda2Applications are placed here - separated from the base system
/mnt/cf/dev/cfCF card (no applicationss for security reasons)
/mnt/vcf/dev/loop1The 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.

Filtering

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:

  1. cardInfoString() and installLocationsString() are now implemented as a filter and a FileSystem list to the String function.
  2. LocationCombo has a new setFilter() function used to limit the types of file systems it shows.
  3. All code using StorageInfo::fileSystems() is updated and the filter argument is mandatory.

Non-removable vs Removable Storage

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

Using read-only file systems have a number of benefitsa:


Copyright © 2006 Trolltech Trademarks
Qtopia 4.1.7