<concept xml:lang="en" id="GUID-3CE3D01D-3EA1-5D44-B9DE-350F9E88F9C9"><title>Structure of paths and filenames</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>A full filename consists of four components:</p> <ul><li id="GUID-FA2E4BB1-3228-5E88-8F78-0BF7EAB14E8B"><p>the drive: a single letter followed by a colon.</p> </li> <li id="GUID-E98DCE36-6BFA-57E4-A03F-8CAB1CE587D1"><p>the path, starting with a backslash and ending with the final backslash in the name. The backslashes divide the path into components.</p> </li> <li id="GUID-32B125E6-9328-5AF0-AEBE-9D64CA801B61"><p>the file name: everything from the character following the last backslash to the character preceding the final dot.</p> </li> <li id="GUID-33B61BC0-F53C-5D50-840A-1EB1B6015227"><p>the extension, which consists of everything after the final dot.</p> </li> </ul> <p>In "8.3" filing systems such as FAT, the meanings of these components are well understood. In non-8.3 systems, the mapping is straightforward, except for the split of the final component of the name between filename and extension. The rule is that anything following the final dot of this component is the extension, anything preceding it is the filename. If there is no dot, or nothing after the final dot, the entire component is the filename, and there is no extension.</p> <p>The following table shows some sample filenames and their component parts:</p> <table id="GUID-395954AC-FB20-5AED-89B2-ADC20F99E435"><tgroup cols="5"><colspec colname="col0"/><colspec colname="col1"/><colspec colname="col2"/><colspec colname="col3"/><colspec colname="col4"/><tbody><row><entry><p>Full name</p> </entry> <entry><p>Drive</p> </entry> <entry><p>Path</p> </entry> <entry><p>Filename</p> </entry> <entry><p>Extension</p> </entry> </row> <row><entry><p><filepath>d:\path\fn.ext</filepath> </p> </entry> <entry><p><filepath>d:</filepath> </p> </entry> <entry><p><filepath>\path\</filepath> </p> </entry> <entry><p><filepath>fn</filepath> </p> </entry> <entry><p><filepath>.ext</filepath> </p> </entry> </row> <row><entry><p><filepath>autoexec.bat</filepath> </p> </entry> <entry/><entry/><entry><p><filepath>autoexec</filepath> </p> </entry> <entry><p><filepath>.bat</filepath> </p> </entry> </row> <row><entry><p><filepath>c:\readme</filepath> </p> </entry> <entry><p><filepath>c:</filepath> </p> </entry> <entry><p>\</p> </entry> <entry><p><filepath>readme</filepath> </p> </entry> <entry/></row> <row><entry><p><filepath>c:readme</filepath> </p> </entry> <entry><p><filepath>c:</filepath> </p> </entry> <entry/><entry><p><filepath>readme</filepath> </p> </entry> <entry/></row> <row><entry><p><filepath>.profile</filepath> </p> </entry> <entry/><entry/><entry/><entry><p><filepath>.profile</filepath> </p> </entry> </row> <row><entry><p><filepath>..</filepath> </p> </entry> <entry/><entry/><entry><p><filepath>..</filepath> </p> </entry> <entry/></row> </tbody> </tgroup> </table> <p>Note that not all parts need be present. Note also that the directory navigators <filepath>..</filepath> and <filepath>.</filepath> are not an intrinsic part of the file system model, and are not therefore supported directly in names.</p> <p>A directory is identified by a trailing slash: thus, <filepath>c:\wrd\</filepath> indicates a directory, but <filepath>c:\wrd</filepath> indicates a file with no extension. This mandatory requirement allows parsing to function without ambiguity, and also without reference to any session with the file server.</p> <p>The classes described here are used to handle all filename parsing requirements in a uniform way. Because they handle the logic consistently, and because this logic contains some subtle rules, you should always use them rather than writing your own code.</p> </conbody></concept>