h6. [[FileSwitch]] h6(. » [[FileSwitch Technical Details|Technical Details]] h6((. » Key Features h2. Key Features h2(#filenames). Filenames Earlier versions of RISC OS only supported filenames with a length of up to ten characters. This restriction has now been removed from version 4.02 onwards. The storage medium used must, however, support long filenames for this to work. [[FileSwitch]] unlike many other Operating Systems makes no distinction between upper and lower case filenames. i.e A file named 'john' is the same as 'John' or 'JOHN'. Certain characters have special meanings and cannot be used within a filename. A general rule of thumb is not to use top-bit-set characters, even though [[FileCore]] can support them. Here is a list of characters that cannot be used. |_<^{width:4em}. Character|_<^. Meaning| |<^. .|<^. Used to separate directories (similar to / on other OSs)| |<^. :|<^. Introduces a drive or disc. e.g :0, :HardDisc. It also marks the end of a filing system name. e.g adfs:| |<^. *|<^. A wildcard to match zero or more characters| |<^. #|<^. A wildcard to match any single character| |<^. $|<^. Is the name of the root directory of the disc| |<^. &|<^. Is the User Root Directory (URD)| |<^. @|<^. Is the currently selected directory (CSD)| |<^. %|<^. Is the currently selected library directory (CSL)| |<^. \|<^. Is the previously selected directory (PSD)[1]| |<^. ^|<^. Is the parent directory| fn1. Available on FileCore-based filing systems, and any other that choose to do so. Note: In RISC OS 2, wildcard matching would be specific to either file or folders, but not both. Later versions of RISC OS changed this, so that a wildcard match would act on all file objects. i.e it will try and find a match on both files and directories. h2(#directories). Directories Directories, also known as folders on other Operating Systems, are used to group lots of files, and possible other directories together. Objects within the currently selected directory may be accessed without reference to the directory name. The names of objects must be unique within a directory. The root directory of a storage medium is accessed via $ character. As $ is the root directory, there is no parent, and trying to access its parent will simply result in access to the root directory. File in directories other than the root directory can be accessed by either prefixing the desired object with a directory path, or by setting the currently selected directory (CSD) and then accessing the object. The use of the '.' (period) character is used to separate directories in a hierarchal structure. |_<^{width:4em}. Path|_<^. Meaning| |<^. <code>$.Photos.Wedding001</code>|File 'Wedding001' in directory Photos in $| |<^. <code>Holidays.Miami</code>|<^. File 'Miami' in directory Holidays within currently selected directory| h2(#file_attributes). File Attributes File attributes are used to store information relating to the read/write access available. They are stored using 4 bytes (32 bits). The top 24 bits are filing system dependent, where as the lower byte has the following standardised interpretation: |_<^{width:4em}. Bit|_<^. Meaning if set| |<^. 0|<^. Object has read access for user| |<^. 1|<^. Object has write access for user| |<^. 2|<^. Owner execute only[1], or private[2]| |<^. 3|<^. Object is locked against deletion by user| |<^. 4|<^. Object has public read access| |<^. 5|<^. Object has public write access| |<^. 6|<^. Hidden (Filer+)| |<^. 7|<^. Application (Filer+)| fn1. Applies to BBC ADFS only fn2. Applies to SJ Research file servers only If both bits 6 & 7 are set, then the file is super-hidden. The top 24-bits are filing system dependant. e.g. [[NetFS]] uses them to store the date. Filing systems that have been created to use the features of [[FileCore]], such as [[ADFS]] and [[RamFS]], ignore the settings of bits 4 and 5. This is so that files can be moved freely between ADFS, RamFS and [[NetFS]] without losing information on their public read and write access. Bits 2, 6 and 7 should be cleared when creating file attributes for a file, as they may be of use in future versions of RISC OS. h2(#file_type). File Type Unlike many other Operating Systems, RISC OS does not use file extensions as its native method of identifying the type of file. Instead, a three digit hexadecimal code, that is not part of the file name, is used instead. Applications that can load and/or save a file of a specific type, usually inform the Operating System of this, and can assign a Sprite to the file type. Any files 'seen' by the Filer will then automatically display files of that type with the sprite, and if double-clicked upon, will use the application to load the file. The file type information is stored as part of the "Load and Execution":#load_execution Address fields. File types are split intro three distinct categories: |_<^{width:8em}. Value|_<^. Meaning| |<^. &000 - &0FF|<^. Personal use only| |<^. &100 - &3FF|<^. Non-commercial software| |<^. &400 - &9FF|<^. Commercial software| |<^. &A00 - &AFF|<^. Commercial software (ex AcornSoft)| |<^. &B00 - &DFF|<^. Commerical software| |<^. &E00 - &FFF|<^. Reserved by Operating System| It is possible to list the file types currently known by the computer at any given time, by using the following command. <code>*Show File$Type_*</code><br /> For a list of commonly used file types by RISC OS, please see the [[File Types]] section. h2(#load_execution). Load and Execution Addresses All files have in addition to their name, length, type and attributes, two 32-bit fields that are used to describe the file. These are set when the file is first created, and have two possible meanings. # Load and Execution Addresses # File type and Date Stamps In the case of a simple machine code program, two memory addresses are specified; the load address specifies the memory address where the file should be loaded, and the execution address specifies where the program should commence. The table below shows the format of the memory addresses: |<^. Load address|_<^. <code>&XXXLLLLL</code>| |<^. Execution address|<^. <code>&GGGGGGGG</code>| *Note:* The execution address must fall within the load address and load address + the length of file. In addition, if the top twelve bits of the load address are all set (XXX = &FFF), then the file is assumed to be date-stamped. h2(#date_stamp). Date Stamp If the top 12 bits of the load address are all set (see Load and Execution Addresses), then the remaining bits are used to store the date/time stamp of when the file was created or last modified, and the file type. The date/time stamp uses 5 bytes (unsigned) to store the value. The start value begins at 00:00:00 1[^st^] January 1900, and each successive value is in centi-seconds. The most significant byte of the date is actually stored in the least significant byte of the load address field. The format of how the data is stored using each of the 32 bit fields are shown below: |<^. Load address|_<^. <code>&FFFtttdd</code>| |<^. Execution address|<^. <code>&dddddddd</code>| Where <code>d</code> is part of the date, and <code>t</code> is part of the file type. h4. See also h5. Other languages documentation [[FileSwitch Key Features (français)|Français]]