<?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 id="GUID-AF65EC50-0922-57DD-809B-DB8970C8E4C6" xml:lang="en"><title>File
server session</title><shortdesc>This topic describes the file server session concept.</shortdesc><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>