<?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>