[Freedos-32-dev] The FD32 File System Manager, part I

[Salvo I. <sa...@li...>]

Hello,
here's a draft of the first part of the File System Manager specification,
the FD32 layer that will be responsible of global managing of files, issuing
the appropriate file system drivers functions.

Please have a look to this and post opinions.
Bye,
Salvo/Sampled Sensations
E-mail: salvo AT sampsens.cjb.net
Sampled Sensations - digital music : http://www.sampsens.cjb.net
FreeDOS 32 - the 32-bit DOS        : http://freedos-32.sourceforge.net
PGP Key Fingerprint: 5991 4C97 D4D8 0B3D BA43  5398 BE9F 07E8 4CD2 1042

-----------------------------------------------------------------------

FILE NAMES
----------
Since FD32 is supposed to deal with many file system types, the preferred
file names will be long file names, long up to 255 bytes, including the null
terminator. A full path can be long up to 260 bytes, including the null
terminator.

The character set to be used for long file names will be Unicode in UTF-8
encoding. Unicode has been chosen for maximum generality and because it is
native character set of long file names in FAT, Joliet and possibly other
file systems. UTF-8 has been chosen for maximum compatibility with standard
applications and compilers, in order to use the standard C type 'char'.

Since devices are identified with file names, the same rules apply for
device names.

The FD32 native interface will expect Unicode UTF-8 long file names, but
standard DOS applications use ASCII instead. Hence, the INT 21h handler
(that will be a wrapper for the FD32 native interface) will perform all
necessary conversions.

For backward compatibility, APIs for short file names will be provided too,
but they are not supposed to work with file systems other than FAT or ISO
9660 CD-ROM with Level 1 Interchange. Those APIs will expect file names in
ASCII, that will be written into the file system without any conversion.
Moreover ISO 9660 has the limitation of d-characters (A-Z, 0-9, and _).

A short file name can be up to 14 bytes long, including the null terminator,
and a full path of short names can be up to 64 bytes long, including the
null terminator.


HOW TO IDENTIFY A DRIVE
-----------------------
A drive specification is identified as the first part of a path name
preceding a colon (':'). It seems to be no reason to have drive
specifications of one letter only, however standard drives will be named
with a single letter as in standard DOS. Drive specifications more than one
letter long can be used, for example, for special drives like "DEV", that is
a virtual drive containing all FD32 devices, and "MODULES", that is a
virtual drive containing the MultiBoot modules loaded at startup.

If no colon is present into a path name, then the use of the default drive
is assumed. The File System Manager will own a string variable to store the
default drive:

static char DefaultDrive[FD32_MAX_LFN_PATH_LENGTH];

Each drive will have a device in the FD32 devices list. The name of such a
device will be the drive specification itself, e.g. the drive "A" will
correspond to a device named "A". The type of such a device will be
FD32_DRV_FILESYSTEM, to identify a file system hosting device, that is a
drive.


HOW TO MANAGE OPENED FILES
--------------------------
Opened files are identified by applications by an integer handle, that is an
index for the JFT (Job File Table). The JFT is an array of bytes, contained
into the application's PSP if smaller than 20 bytes, or pointed by a pointer
present into the PSP if greater than 20 bytes. The size of the JFT is also
stored into the PSP.

Under DOS each entry of the JFT is an index for the list of SFTs (System
File Tables), that are structures describing each opened file (referring
handles, opening mode, current position and so on). So a handle indexes the
JFT that indexes the SFT. When a "dup" (duplicate handle) system call is
executed, a new entry of the JFT will point to the same SFT of the first
file.

FD32 cannot implement the SFT in the same way as DOS does, because under
FD32 there are file system drivers, and each driver may need different
structure formats to manage an opened file. So the real SFT-like structures
will be internal to the file system drivers.

Under FD32 the SFT will be an array of structures, that define the device
where each file is located and a file descriptor (an integer handle) to
identify the opened file inside the device. Such a file descriptor will be
returned by the open function of the device driver.

struct
{
  struct Device *D;  /* Pointer to the device that hosts the file */
  int            Fd; /* File descriptor internal to the device    */
}
Sft[FD32_MAX_FILES];