|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-310A8A9C-98E7-59EE-9376-8E572580190F" xml:lang="en"><title>File |
|
13 services in Symbian platform</title><shortdesc>This topic describes the common concepts of file systems and files |
|
14 used by Symbian platform.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
15 <p>Like other software systems, Symbian platform can store data so that it |
|
16 is kept when a handset is powered down. </p> |
|
17 <p>On PCs, a file is kept on magnetic disk or optical media such as CD or |
|
18 DVD. On older generations of personal organisers, a file was often kept in |
|
19 RAM, needing a permanent power supply, and a backup battery to guarantee this. |
|
20 On the most recent telephone handsets, files are normally stored in flash |
|
21 memory, either NOR flash or NAND flash, and also on removable devices such |
|
22 as MultiMediaCard (MMC), Secure Digital card (SD card), Memory Stick or Compact |
|
23 flash (CF). </p> |
|
24 <p>There are more sophisticated services for persisting data such as streams, |
|
25 stores, central repository etc. that applications can use, but they all rely, |
|
26 either directly or indirectly, on the commonly understood idea of the file. </p> |
|
27 <p>The ROM on a typical handset is located in non-volatile flash memory, allowing |
|
28 it to be upgraded by the handset manufacturer after initial production. The |
|
29 location for user data is almost always flash memory (NAND or NOR), on the |
|
30 grounds of cost, although rotating media devices capable of holding large |
|
31 amounts of data are likely in future handsets. </p> |
|
32 <ul> |
|
33 <li id="GUID-798E9ED1-24DF-5990-9D1E-CD043B94B722"><p> <xref href="GUID-310A8A9C-98E7-59EE-9376-8E572580190F.dita#GUID-310A8A9C-98E7-59EE-9376-8E572580190F/GUID-DD8C4BFB-9816-5EA5-A9F2-5146C64BBC9C">Basic concepts</xref> </p> </li> |
|
34 <li id="GUID-BBB6D4C2-4AE6-55CD-BC65-416BCF705F31"><p> <xref href="GUID-310A8A9C-98E7-59EE-9376-8E572580190F.dita#GUID-310A8A9C-98E7-59EE-9376-8E572580190F/GUID-62387DD0-D8E4-5426-8432-B14696291AF8">Accessing file services</xref> </p> </li> |
|
35 <li id="GUID-B6AEF9DA-60D3-5728-9C46-59EE5C98346C"><p> <xref href="GUID-310A8A9C-98E7-59EE-9376-8E572580190F.dita#GUID-310A8A9C-98E7-59EE-9376-8E572580190F/GUID-9FF4525A-EBFD-5E9F-BD86-C6B75E5C35EF">Security issues</xref> </p> </li> |
|
36 <li id="GUID-ACF583E3-3FAA-52FE-9A07-8172A4BBBCC9"><p> <xref href="GUID-310A8A9C-98E7-59EE-9376-8E572580190F.dita#GUID-310A8A9C-98E7-59EE-9376-8E572580190F/GUID-849F5D6E-7911-55F8-839A-019D1BF16726">File systems and mounting a drive</xref> </p> </li> |
|
37 </ul> |
|
38 <section id="GUID-DD8C4BFB-9816-5EA5-A9F2-5146C64BBC9C"><title>Basic concepts</title> <p>Symbian |
|
39 platform uses a number of file concepts that are common to most operating |
|
40 systems, for example, drives and directories. </p> <p><b>Drives</b> </p> <p>Symbian |
|
41 platform uses the concept of the <i>drive</i>. This idea is similar to that |
|
42 in other operating systems, i.e. it corresponds to a logical device. A media |
|
43 device such as a MultiMediaCard can be logically split into partitions, and |
|
44 each partition is treated as a separate drive. Symbian platform adopts a DOS-like |
|
45 convention where each drive is identified by a single letter. This means that |
|
46 there can be up to 26 drives on a handset, identified by the letters <filepath>A:</filepath> through |
|
47 to <filepath>Z:</filepath>. In practice, there are far fewer than this, and |
|
48 the number depends on the individual manufacturer's handset </p> <p>Internally, |
|
49 Symbian platform uses the idea of a drive number instead of a letter, and |
|
50 some legacy API items take a drive number as input, or return a drive number |
|
51 as output. However, there are functions that can translate drive numbers to |
|
52 and from drive letters: <xref href="GUID-E263C747-946F-35AA-9F1D-41833BD350FC.dita#GUID-E263C747-946F-35AA-9F1D-41833BD350FC/GUID-A0F50C51-A4F0-33C1-BBD4-757DEC4B7F2E"><apiname>RFs::DriveToChar()</apiname></xref> and <xref href="GUID-E263C747-946F-35AA-9F1D-41833BD350FC.dita#GUID-E263C747-946F-35AA-9F1D-41833BD350FC/GUID-D545B868-0549-37A9-AACE-288E7C9CE8C3"><apiname>RFs::CharToDrive()</apiname></xref>. </p> <p>The |
|
53 main ROM on a handset is always identified as the <filepath>Z:</filepath> drive. |
|
54 Other drives may be in use: sixteen of the drives <filepath>C:</filepath> to <filepath>R:</filepath> are |
|
55 usually reserved as local drives, i.e. for media devices located within the |
|
56 handset. A common convention is to adopt <filepath>C:</filepath> as the main |
|
57 user data drive. and to designate <filepath>D:</filepath> or <filepath>E:</filepath> as |
|
58 drives for removable media. <i>Be aware</i>, however, that this is a convention |
|
59 that some handset manufacturers may not follow, so you are always advised |
|
60 to check the full SDK that applies to a specific handset for guidance. Indeed, |
|
61 as a matter of principle, you should always use the <xref href="GUID-629AB2C9-BEDD-5166-8B09-F8DFF7527C03.dita">system |
|
62 drive</xref> for user data. </p> <p><b>Volume</b> </p> <p>The concept of the volume applies to removable media. As users insert |
|
63 and remove individual devices, so different volumes are said to be mounted |
|
64 and demounted. For media types that can be split into partitions, each partition |
|
65 corresponds to a separate volume. </p> <p><b>File |
|
66 names and directory structures</b> </p> <p>Files have names, and Symbian platform |
|
67 uses a hierarchical directory structure in which to organize them; this is |
|
68 similar to schemes adopted by other operating systems. For example: </p> <codeblock id="GUID-C4330879-E93B-5939-A810-8D4A1E5B14DB" xml:space="preserve">C:\AAA\BBB\CCC\DDD.EXT</codeblock> <p>There |
|
69 are four main parts to the structure: </p> <ul> |
|
70 <li id="GUID-39D18587-8793-511F-B3CC-8CFA6D129F80"><p>the <i>drive</i>; this |
|
71 is always at the top of the hierarchy, and is represented by a drive letter |
|
72 and a colon. </p> </li> |
|
73 <li id="GUID-8F5F5EB0-721F-5C5B-90B6-08E2CB92BA98"><p>the <i>path</i>; this |
|
74 is a list of names, each name representing a level in the hierarchy. Each |
|
75 directory name is separated by a back slash character, and the last directory |
|
76 name is always terminated by a back slash character. </p> </li> |
|
77 <li id="GUID-BD848A50-9BEA-5E08-ACDB-92EDB9C5CA86"><p>the <i>filename</i>; |
|
78 this is everything after the final backslash, and before the dot if there |
|
79 is a file extension. Symbian platform supports long file filenames. </p> </li> |
|
80 <li id="GUID-07E1D5CB-9D9B-5141-AD7B-76F839AA2FC0"><p>the <i>extension</i>, |
|
81 everything after the final dot. There is no restriction on the length of the |
|
82 extension; limits on length apply to the whole structure, not to any single |
|
83 part of it. </p> </li> |
|
84 </ul> <p>You will find that the whole structure is sometimes referred to as |
|
85 the full file name or the full path name. The maximum length of a full file |
|
86 name is limited to 256 characters. Symbian platform does not use the extension |
|
87 to identify the software or application that can access the data. Instead, |
|
88 files have UIDs embedded within them, and the mapping of files to applications |
|
89 is done through these UIDs. See <xref href="GUID-3AFA877F-41DE-5343-8BC2-C0FB894A062C.dita">Application |
|
90 registration information</xref>. </p> <p>The case of full path names is always |
|
91 preserved, but operations on names are case insensitive. This means that two |
|
92 files that have the same name but differ only in case are considered to refer |
|
93 to the same file. </p> <p>Full file names are normally manipulated programmatically. |
|
94 Extracting drive names, filenames, file extensions, and changing the names |
|
95 of a directory structure are typical activities. Symbian platform provides |
|
96 you with the <xref href="GUID-E79A3B03-F8CB-37DB-A2A8-1C6C4E4D739A.dita"><apiname>TParse</apiname></xref>, <xref href="GUID-A6268E58-68EC-3041-93FD-5368CD230947.dita"><apiname>TParsePtr</apiname></xref>, and <xref href="GUID-C65BCDAB-0476-3EAC-9BFC-37243AE43FE9.dita"><apiname>TParsePtrC</apiname></xref> classes |
|
97 to help you do this manipulation. </p> <p>See <xref href="GUID-ECF9E432-EA93-5284-B0E6-A1211289CBD8.dita">parsing |
|
98 paths and filenames</xref> . </p> </section> |
|
99 <section id="GUID-62387DD0-D8E4-5426-8432-B14696291AF8"><title>Accessing file |
|
100 services</title> <p>On Symbian platform, file services are a common resource. |
|
101 Like other common or shared resources on Symbian platform, file services are |
|
102 handled by a server - the file server. Applications and other software that |
|
103 require access to files, directories and drives are clients of the file server, |
|
104 and send file-related requests using the <xref href="GUID-198DCED1-F429-5C95-A51D-53AE416687E8.dita">file |
|
105 server client-side API</xref>. </p> <p>The file server is multithreaded, which |
|
106 allows each logical drive to be accessed concurrently. More than one request |
|
107 can be issued for the same drive, but these requests are handled sequentially. |
|
108 For example, a request to read or write data to a MultiMediaCard can be handled |
|
109 at the same time as a request to read or write data to the main user drive. </p> <p>The |
|
110 file server has a main thread that initially handles all requests. Short requests, |
|
111 such as those that require access to the ROM drive, and those that do not |
|
112 require access to any media, run in the file server. </p> <p>The services |
|
113 provided by the file server can be divided into two types: </p> <ul> |
|
114 <li id="GUID-12F7606D-835D-5948-B0F0-EBACC5F6E569"><p>those that give you |
|
115 access to individual files, directories and drives using the <xref href="GUID-BE0804F6-4375-3C8A-8C83-968F510466E0.dita"><apiname>RFile</apiname></xref>, <xref href="GUID-12AE154F-7741-38C0-ADFE-9784FCF5E516.dita"><apiname>RDir</apiname></xref> and <xref href="GUID-9D7E765B-6872-3EB9-9D5B-1503FA466EC1.dita"><apiname>RFormat</apiname></xref> classes. </p> <p>See also <xref href="GUID-30B2AF3F-E120-5D47-AAA2-529555625B55.dita">How to |
|
116 use sessions, files, and directories</xref>. </p> </li> |
|
117 <li id="GUID-9E40CF33-C35E-52CE-80B9-8A019F34F305"><p>those that allow you |
|
118 to do higher level longer running operations such as moving, copying and deleting |
|
119 files, using the <xref href="GUID-82CEC14F-1479-3922-846A-9FCDB6465EF7.dita"><apiname>CFileMan</apiname></xref> class, scanning directory trees |
|
120 using the <xref href="GUID-C657AF2D-1183-3CD2-ACAF-3B0B00FC91BB.dita"><apiname>CDirScan</apiname></xref> class, and tracking the progress of |
|
121 these operations using the <xref href="GUID-E608485F-B3E3-3310-A80E-169D8B9D2234.dita"><apiname>MFileManObserver</apiname></xref> class. </p> <p>See |
|
122 also <xref href="GUID-ACF6C0A2-87ED-55B3-B22A-9B331D9940AC.dita">File management |
|
123 and searching</xref> </p> </li> |
|
124 </ul> <p>Like most other servers, the client API allows you to make file requests |
|
125 synchronously or asynchronously. </p> <p>See also <xref href="GUID-6047DB3F-DC92-51DF-9EEB-00E79E890B54.dita">client-server</xref>. </p> </section> |
|
126 <section id="GUID-9FF4525A-EBFD-5E9F-BD86-C6B75E5C35EF"><title>Security issues</title> <p>Security |
|
127 considerations restrict the parts of a handset's directory structure that |
|
128 an application is allowed to access. The concept is referred to as <i>data |
|
129 caging</i>. </p> <p>There are a number of principles involved: </p> <ul> |
|
130 <li id="GUID-21674EE5-40A3-5F71-9973-C089FD838585"><p>The fundamental principle |
|
131 is the separation of executable code from data. Executable code can only reside |
|
132 in the <filepath>/sys/bin/</filepath> directory. Executables cannot be loaded |
|
133 from any location other than <filepath>/sys/bin/</filepath>. Unless an application |
|
134 has the appropriate system capabilities, the <filepath>/sys/</filepath> directory |
|
135 is not visible to that application. System capabilities are a discrete set |
|
136 of 'permissions' that give access to various sensitive system services, and |
|
137 which can only be granted to applications, if justified, through the <xref href="https://www.symbiansigned.com/app/page" scope="external">Symbian Signed</xref> scheme. </p> </li> |
|
138 <li id="GUID-4A1854CE-25CB-5630-A27C-73931D937567"><p>Applications have their |
|
139 own private directory, under which they are free to create further directory |
|
140 structures and files, and to write to those files. This is the directory structure <filepath>/private/<app_SID>/</filepath>. <i><app_SID></i> is known as a secure identifier and, in general, is used when verifying |
|
141 an executable's rights of access to system resources. Here, it is used to |
|
142 form the path name for the executable's private directory. The secure identifier |
|
143 is a UID which is allocated to a developer through the <xref href="https://www.symbiansigned.com/app/page" scope="external">Symbian Signed</xref> scheme, and is guaranteed to be unique |
|
144 within the handset on which the application is installed. The UID is coded |
|
145 into the <filepath>mmp</filepath> file(s) that define the application's source |
|
146 files, link requirements, and general characteristics. </p> <p>Other applications |
|
147 have no right of access to an application's private directory. </p> </li> |
|
148 <li id="GUID-2814D086-A660-5294-9952-E6D66243B652"><p>There is a directory <filepath>/resource/</filepath> to |
|
149 which all applications have read access, but no write access. The purpose |
|
150 of this directory is to conatin common read-only files. </p> </li> |
|
151 <li id="GUID-FC6EE81A-59FA-5AC5-8EC4-3034597F8829"><p>All other directories |
|
152 are accessible for both reading and writing. This allows the use of standard |
|
153 file system hierarchies that may be available on removable media. </p> </li> |
|
154 <li id="GUID-95121831-873B-5E79-B07C-410858FC9779"><p>The above principles |
|
155 apply regardless of the drive. </p> </li> |
|
156 </ul> <p>It is possible to pass an open file to another process, or between |
|
157 a client and server, so that the target can access the file without knowing |
|
158 the full path name. The only information that is passed to the target is the |
|
159 filename and extension. </p> </section> |
|
160 <section id="GUID-849F5D6E-7911-55F8-839A-019D1BF16726"><title>File systems |
|
161 and mounting a drive</title> <p>The varying characteristics of media types |
|
162 can mean that different media types require different formats. A common format |
|
163 is VFAT, and typically, this is used for removable media to maintain compatibility |
|
164 with other systems. This also means that long file names are supported. </p> <p>In |
|
165 Symbian platform, format schemes are implemented by what are called file systems; |
|
166 they are constructed as plugins to the file server. This means that the file |
|
167 server itself is independent of the format scheme, and also means that a phone |
|
168 manufacturer is free to add new file systems to a handset. The ROM is an exception |
|
169 - it has its own file system built into the main file server code. </p> <p>A |
|
170 file system must be associated with a drive before the drive can be used. |
|
171 This is known as mounting the drive, and is typically done at system boot |
|
172 time. </p> <p>In practice, an application does not need to concern itself |
|
173 with the format scheme. </p> </section> |
|
174 </conbody></concept> |