X-Files: Difference between revisions

From RISC OS
Jump to navigationJump to search
m (switch templates, shorten displayed URLs)
(→‎Long Filename Systems: splitting this bit onto its own page)
Line 10: Line 10:
Note that if RISC OS 3.1 is being run under [[VirtualAcorn]], it is not affected by the infamous 77-file-per-directory limit. VirtualAcorn uses HostFS and thus supports long file names and unlimited files per directory.
Note that if RISC OS 3.1 is being run under [[VirtualAcorn]], it is not affected by the infamous 77-file-per-directory limit. VirtualAcorn uses HostFS and thus supports long file names and unlimited files per directory.


By using an image filing system, X-Files has different advantages and disadvantages to programs such as [[LongFiles]] or [[raFS]]. These differences are discussed in this article on [[Long Filename Systems]]
=== Long Filename Systems ===


When X-Files is not running, an X-File image file is a monolithic object, and individual files within the X-File image cannot be accessed or manipulated. This is quite similar to the behaviour of compressed files within an archive being managed by [[ArcFS]] or [[SparkFS]].
By using an image filing system, X-Files has different advantages and disadvantages to programs such as [[LongFiles]] or [[raFS]]:

LongFiles only addresses the problem of long filenames, not the ADFS 77-file-per-directory limit. In fact, the hidden file used by LongFiles to store long filename information ''reduces'' the number of files available in a directory to 76. However, those files remain accessible even when the LongFiles module is not active; only the long filename information is unavailable.

When X-Files is not running, an X-File image file is a monolithic object, and individual files within the X-File image cannot be accessed or manipulated. This is quite similar to the behaviour of files within an archive being managed by [[ArcFS]] or [[SparkFS]].

raFS works differently again; files are stored in a custom directory structure using the underlying file system. This structure is hidden from the user while raFS is running, and gives unlimited files per directory with unlimited-length names. When raFS is not running, the long filenames and long sub-directory names are unavailable, but individual files can be retrieved separately from one another.

Revision as of 09:47, 22 November 2007

X-Files
Icon:
X-Files icon
Maintained by: {{{maintainer}}}
Description: X-Files allows users of RISC OS 3.71 and below to have as many files and directories (with names longer than ten characters) in a single directory as they wish. X-Files is implemented as an Image Filing System.
OS Restrictions: Not 32-bit compatible
Languages: {{{languages}}}
Alternatives: raFS, SparkFS, Win95FS, other image filing systems
Website: Mirror only

Historical Notes

Andy Armstrong wrote X-Files in 1996, having apparently seen the 'Directory full' error message (triggered by attempting to save a 78th file into a directory) one time too many.

X-Files is now very tricky to find but version 0.57 (which is believed to be the last version) can be downloaded from www.mirror.ac.uk or ftp.uni-stuttgard.de, including the source code and a data recovery tool in case something goes wrong.

RISC OS has had long filename support since the release of RISC OS 4 in 1999, so this utility is only needed to read ancient data saved on old-format disks (E or F format or earlier) under RISC OS versions 3.71 and earlier.

Note that if RISC OS 3.1 is being run under VirtualAcorn, it is not affected by the infamous 77-file-per-directory limit. VirtualAcorn uses HostFS and thus supports long file names and unlimited files per directory.

By using an image filing system, X-Files has different advantages and disadvantages to programs such as LongFiles or raFS. These differences are discussed in this article on Long Filename Systems

When X-Files is not running, an X-File image file is a monolithic object, and individual files within the X-File image cannot be accessed or manipulated. This is quite similar to the behaviour of compressed files within an archive being managed by ArcFS or SparkFS.