Showing changes from revision #8 to #9:
Added | Removed | Changed
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.
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 |
1 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.
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.
Path | Meaning |
---|---|
$.Photos.Wedding001 |
File ‘Wedding001’ in directory Photos in $ |
Holidays.Miami |
File ‘Miami’ in directory Holidays within currently selected directory |
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:
Bit | Meaning if set |
---|---|
0 | Object has read access for user |
1 | Object has write access for user |
2 | Owner execute only1, or private2 |
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+) |
1 Applies to BBC ADFS only
2 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.
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 Address fields.
File types are split intro three distinct categories:
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.
*Show File$Type_*
For a list of commonly used file types by RISC OS, please see the File Types section.
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.
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 | &XXXLLLLL |
---|---|
Execution address | &GGGGGGGG |
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.
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 1st 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 |
|
---|---|
Execution address | &dddddddd |
Where d
is part of the date, and t
is part of the file type.