<?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-44927609-CFD1-5D09-BA78-7A5AB981DD2E"><title>Files and Directories</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>This section explains the file, path and directory names usage in STDLIB. </p> <p>The Symbian platform file system APIs require all file names to be fully specified, possibly by using default components in the session path. For more information, see the documentation on the file server (<xref href="GUID-198DCED1-F429-5C95-A51D-53AE416687E8.dita">File server</xref>). In particular, the file system does not support the notion of a "relative path" which uses "." and ".." to navigate relative to a "current working directory". STDLIB does support this and does not require fully qualified paths, with the constraint that any pathname beginning with "&lt;letter&gt; :" will be treated as an absolute path from the root of the specified drive. STDLIB allows the drive letter '?' to mean "any drive". This can be useful when a file or directory is known to exist but it could be on any drive. STDLIB allows both "/" and "\" as directory separators, unlike the underlying Symbian file system which recognises only "\". </p> <p>The current working directory is a process-wide resource (similar to the file descriptor table), so the <codeph>CPosixServer</codeph> will provide a single process-wide current working directory. However, when using the "single-threaded" mode of operation, each thread will have a separate current working directory. </p> <p>The following table gives some examples, all based on a working directory of <filepath>c:\documents\stdlib</filepath>  </p> <table id="GUID-5F0DA1ED-CAAA-522E-8BC9-DD53D3076E63"><tgroup cols="3"><colspec colname="col0"/><colspec colname="col1"/><colspec colname="col2"/><tbody><row><entry><p> <b>Pathname</b>  </p> </entry> <entry><p> <b>In Symbian platform</b>  </p> </entry> <entry><p> <b>In STDLIB</b>  </p> </entry> </row> <row><entry><p> <filepath>c:\documents\stdlib\</filepath>  </p> </entry> <entry><p>current directory </p> </entry> <entry><p>current directory </p> </entry> </row> <row><entry><p> <filepath>c:\documents\stdlib</filepath>  </p> </entry> <entry><p>illegal (not a file) </p> </entry> <entry><p>current directory </p> </entry> </row> <row><entry><p> <filepath>.</filepath>  </p> </entry> <entry><p>illegal </p> </entry> <entry><p>current directory </p> </entry> </row> <row><entry><p> <filepath>..</filepath>  </p> </entry> <entry><p>illegal </p> </entry> <entry><p>c:\documents </p> </entry> </row> <row><entry><p> <filepath>examples</filepath>  </p> </entry> <entry><p>filename </p> </entry> <entry><p>c:\documents\stdlib\examples </p> </entry> </row> <row><entry><p> <filepath>..\examples </filepath>  </p> </entry> <entry><p>illegal </p> </entry> <entry><p>c:\documents\examples </p> </entry> </row> <row><entry><p> <filepath>d:examples </filepath>  </p> </entry> <entry><p>illegal </p> </entry> <entry><p>d:\examples </p> </entry> </row> <row><entry><p> <filepath>?:\system\data\ </filepath>  </p> </entry> <entry><p>illegal </p> </entry> <entry><p>c:\system\data (if file exists on c) or d:\system\data (if it exists on d but not on c) or z:\system\data (if it exists in the ROM). </p> </entry> </row> </tbody> </tgroup> </table> <p>In summary, the POSIX and STDLIB handling of pathnames is DOS-like, with the exception that there is not a separate working directory per drive. </p> <p>The Symbian file system supports DOS-like attributes, rather than POSIX-like permissions. STDLIB cannot therefore provide the full POSIX-like handling of file attributes and implements only "user read permission". </p> <p>STDLIB's implementation of <codeph>fseek()</codeph>, unlike some other implementations, does not allow you to seek beyond the end of a file and expand the file to the new position. </p> <section><title>See also</title> <p> <xref href="GUID-198DCED1-F429-5C95-A51D-53AE416687E8.dita">File server</xref> </p> </section> </conbody></concept>