66 lines
3.3 KiB
HTML
66 lines
3.3 KiB
HTML
<html><head>
|
|
<title>HPFS: Extended Attributes</title>
|
|
</head>
|
|
|
|
<body>
|
|
<center>
|
|
<h1>Extended Attributes</h1>
|
|
</center>
|
|
|
|
File attributes are information about a file that is maintained by the
|
|
operating system outside the file's overt storage area. The FAT file
|
|
system supports only a few simple attributes (read only, system, hidden,
|
|
and archive) that are actually stored as bit flags in the file's directory
|
|
entry these attributes are inspected or modified by special function calls
|
|
and are not accessible through the normal file open, read, and write calls.
|
|
The HPF'S supports the same attributes as the FAT file system for historical
|
|
reasons, but it also supports a new form of file- associated, highly
|
|
generalized information called Extended Attributes (EAs). Each EA is
|
|
conceptually similar to an environment variable, taking the form
|
|
(name=value) except that the value portion can be either a null- tenninated
|
|
(ASCIIZ) string or binary data. In OS/2 1.2, each file or direc-tory can
|
|
have a maximum of 64Kb of EAs attached to it. This limit may be lifted in
|
|
a later release of OS/2. The storage method for EAs can vary. If the EAs
|
|
associated with a given file or directory are small enough, they will be
|
|
stored right in the Fnode. If the total size of the EAs is too large, they
|
|
are stored outside the Fnode in sector runs, and a B+ Tree of allocation
|
|
sectors can be created to describe the runs. If a single EA gets too large,
|
|
it can be pushed outside the Fnode into a B+ Tree of its own.
|
|
<p>
|
|
The kernel API functions DosQFileInfo and DosSetFileInfo have been expanded
|
|
with new information levels that allow application programs to manipulate
|
|
extended attributes for files. The new functions DosQPathInfo and
|
|
DosSetPathInfo are used to read or write the EAs associated with arbitrary
|
|
path names. An application program can either ask for the value of a
|
|
specific EA (supplying a name to be matched) or can obtain all of the EAs
|
|
for the file or directory at once. Although application programs can begin
|
|
to take advantage of EAs as soon as the HPFS is released, support for EAs
|
|
is an essential component in Microsoft's long-range plans for object-oriented
|
|
file systems. Information of almost any type can be stored in EAs, ranging
|
|
from the name of the application that owns the file to names of dependent
|
|
files to icons to executable code. As the HPFS evolves, its facilities for
|
|
manipulating EAs are likely to become much more sophisticated. It's easy to
|
|
imagine, for example, that in future versions the API might be extended with
|
|
EA functions that are analogous to DosFindFirst and DosFindNext and EA data
|
|
might get organized into B-Trees. I should note here that in addition to EAs,
|
|
the LAN Manager version of HPFS will support another class of fil-associated
|
|
information called Access Control Lists (ACLs). ACLs have the same general
|
|
appearance as EAs and are manipulated in a similar manner, but they are used
|
|
to store access rights, passwords, and other information of interest in a
|
|
networking multi user environment.
|
|
|
|
<p>
|
|
<hr>
|
|
|
|
< <a href="dirs.html">[Directories]</a> |
|
|
<a href="hpfs.html">[HPFS Home]</a> |
|
|
<a href="ifs.html">[Installable File Systems]</a> >
|
|
|
|
<hr>
|
|
|
|
<font size=-1>
|
|
Html'ed by <a href="http://www.seds.org/~spider/">Hartmut Frommert</a>
|
|
</font>
|
|
|
|
</body></html>
|