Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 72
Текст из файла (страница 72)
Examples include:– SetSubst() to create a substitute drive – one drive acting asshortcut to a path on another– AddFileSystem() to add a file system to the file server– MountFileSystem() to mount a file system on a drive.9.2.2 Sub-session objectsA client may use a session to open and access many different files anddirectories, and F32 represents each of these by a separate object whileit is in use by the client. These objects are known as sub-session objects.There are four sub-session classes:• The RFile class for creating and performing operations on files• The RDir class for reading entries contained in a directory• The RFormat class for formatting a drive• The RRawDisk class, which enables direct drive access.Creating sub-sessions is much less expensive than opening new sessions.Sub-sessions provide an independent channel of communication withinthe session.
If a client closes a session, the file server automatically closesany associated sub-sessions. This ensures that all fileserver resources areproperly freed.342THE FILE SERVERRSessionBaseClose()RFsiSession1nRFileRSubSessionBaseiSubSessionHandle : TIntRDirRFormatRRawDiskConnect()Figure 9.2 F32 client-side classesFigure 9.2 shows these client-side classes.RSessionBase is the base class for a handle to a session with anySymbian OS server. We derive from this in the file server to providethe RFs class.
RSubSessionBase is the client-side handle to a subsession. From this, we derive the RFile, RDir, RFormat and RRawDisksub-session classes that I’ve already introduced.As I will explain later, each of these client-side session and sub-sessionobjects has a corresponding object on the server-side. Should the clientthread terminate unexpectedly before closing the session, then the kernelwill send a disconnect message to the file server which will close thesession and all its sub-session objects.It is good practice to close the sub-session objects as soon as they arefinished with – to free the corresponding server-side resources involved.Otherwise they will remain allocated until the owning session is closed.9.2.2.1 RFile class – for creating and performing operations on filesThe RFile class represents an individual file.
It provides methods tocreate a new file and open an existing file, as well as methods to readfrom and write to a file, seek to a position within a file, and get or set afile’s attributes.When a client opens a file, it specifies a sharing mode which indicateshow (if at all) other programs can access the same file while it is open.If it opens a file with exclusive access, then no other client can accessthe file until the first client closes it.
Read-only sharing means that otherclients may access the file – but only for reading. Finally, a client canopen a file and allow shared access with other clients for both readingand writing. If a file is already open for sharing, then another programcan only open it using the same share mode as that with which it wasoriginally opened. The client can also specify an access mode indicatingTHE FILE SERVER CLIENT API343how the file will be accessed by this particular RFile object. This canspecify either read-only access or read/write access. The access modehas to be compatible with the sharing mode.The RFile class also provides methods to lock and unlock a range ofbytes within a file. A locked region is accessible only through the RFileobject that claimed the lock.
Locking can be used to synchronize updatesto a file when more than one program has read/write access to it.There are a number of variants of the file read and write methods,including synchronous and asynchronous versions. The synchronousversion sends the message to the server and waits for the response,suspending the client thread. The asynchronous version returns as soonas the message is sent, allowing the client thread to continue executionwhile the server processes the request; the client supplies a reference toa TRequestStatus object, which the file server signals on completion.The RFile class also provides methods to read or to change thevarious attributes of a file, such as RFile::Size() to return the size ofa file in bytes and RFile::SetSize() to change the size of a file.9.2.2.2 RDir class – for reading directory entriesThis class is used to read the entries contained in a directory.
Likethe RFile class, it contains both synchronous and asynchronous readmethods.9.2.2.3 RFormat class – for formatting a driveThis class is only used when formatting a drive. This process can take agreat deal of time for a large drive, and so the operation is performed instages, with control returning to the client at the end of each stage.
Stagescan be performed synchronously or asynchronously. A drive cannot beformatted while any client has files or directories open on it.9.2.2.4 RRawDisk class – for direct drive accessThis class is used for direct disk access – allowing raw read and writeoperations to the drive. As with formatting, direct access cannot takeplace while files or directories are open on the drive.9.2.3 High level file server servicesSymbian OS supports a variety of high-level file server services.
Weimplement this higher-level functionality within the client library ratherthan the server, and each API generally leads to a sequence of calls beingmade to the file server.CFileMan provides file management services such as moving, copying and deleting one or more files in a path.
It allows the client to344THE FILE SERVERuse wildcards in the specification of the paths and files concerned.CFileMan methods can be configured to operate recursively, whichmeans that they will act on all matching files that they find throughout the source directory’s hierarchy. These functions may be performedsynchronously or asynchronously.
When they operate asynchronously,the operation takes place in a separate thread from the calling clientthread. The CFileManObserver class allows user notification duringthe operation.The TFindFile class provides methods to search for files in one ormore directories either on a single drive or on every available drive inturn.
We provide versions of this that accept wildcards in the file specifier.CDirScan is used to scan through a directory hierarchy, upwardsor downwards, returning a filtered list of the entries contained in eachdirectory.9.2.4 File namesThe file server supports long file names. A full file name may contain upto 256 16-bit characters and consists of four components:• The drive – a single letter and a colon• The path – a list of directories separated by backslashes which startsand ends with a backslash• The filename – this consists of every character from that which followsthe last backslash to the character preceding the final dot (if anextension is specified)• The extension – which consists of every character after the final dot(after the final backslash).For example: ‘c:\dirA\dirB\dirC\file.ext’.Symbian provides three classes for parsing filenames, each derived fromTParseBase (the base class for filename parsing).
All three classes allowyou to test whether a particular component is included in a specifiedfilename, and if so, to extract it:• TParse – this version contains a TFileName object as a buffer tostore a copy of the parsed filename. TFileName defines a descriptorlong enough to hold the longest file name.
Being 256 characters long,it is a relatively large object and should be used with care. For instance,you should avoid allocating or passing a TFileName on the stack• TParsePtr – this version refers to an external, modifiable buffer• TParsePtrC – This version refers to an external buffer that cannotbe modified.THE FILE SERVER CLIENT API345The last two versions should be used in preference to the first to minimizestack usage.9.2.5 Data caging and sharing file handlesThe EKA2 version of Symbian OS is normally built with platform securityenabled.
In this secure version, the file server employs the data cagingscheme, which I described in Chapter 8, Platform Security.The central theme of data caging is that the file server designates acertain area on the drives that it controls as a restricted system area. Thisarea is only accessible to programs that are part of the Trusted ComputingBase (TCB) – that is the kernel, the file server, and the software installer.All executables are located within this system area and the OS will refuseto execute code from anywhere else.
In addition, each non-TCB processhas its own individual private file area that only it (and a small numberof other special components) has access to. We provide a third resourcearea, which is read-only for non-TCB processes and holds read-only filesthat are to be shared publicly.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
