<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept xml:lang="en" id="GUID-AF65EC50-0922-57DD-809B-DB8970C8E4C6"><title>File server session</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>All files are handled by the file server, using either its local file system, or an installed file system. The server manages i/o activity, and contention, sharing and locking. </p> <p>Client programs access the file server through a client API defined in <filepath>f32file.h</filepath>. This API includes all classes and functions needed for file system, device, directory and file access, and associated utilities. </p> <p>All access from client to server is through a file server session, an instance of the <codeph>RFs</codeph> class. After a client has connected an <codeph>RFs</codeph> to the file server, it can perform any file-related operation. An <codeph>RFs</codeph> is associated with a single current path: when a connection to the file server is made the session path is automatically set to the private directory of the connecting process. </p> <p>After operations have been completed, file server-related clean-up should be carried out using <codeph>Close()</codeph> defined in the <codeph>RHandleBase</codeph> class. Note that for the majority of functions, when a file or directory name is passed as an argument to the function, if no drive letter or directory is specified, the missing path component will be taken from the <keyword>session path.</keyword> </p> <p><b>Component-based design </b> </p> <p>Only a single path is supported, and the path includes the drive. Each component must have its own <codeph>RFs</codeph> for its file access purposes. This gives each component all the flexibility it needs to maintain its own current path and other settings related to an <codeph>RFs</codeph>. There is no limit on the number of <codeph>RFs</codeph> handles available to a single thread. </p> <p>This is unlike DOS, which effectively maintains 26 current paths, one for each drive. DOS also maintains a current drive, and the effective current path is therefore the current path on the current drive. </p> </conbody></concept>