- Table of Contents
- Copyright
- About the Authors
- About the Contributors
- Acknowledgments
- Tell Us What You Think!
- Introduction
- How to Use This Book
- What You Need to Use This Book
- What's New in Visual C++ 6.0
- Contacting the Main Author
- Part I: Introduction
- Chapter 1. The Visual C++ 6.0 Environment
- Part II: MFC Programming
- Chapter 2. MFC Class Library Overview
- Chapter 3. MFC Message Handling Mechanism
- Chapter 4. The Document View Architecture
- Chapter 5. Creating and Using Dialog Boxes
- Chapter 6. Working with Device Contexts and GDI Objects
- Chapter 7. Creating and Using Property Sheets
- Chapter 8. Working with the File System
- File System Overview
- Win32 File Objects
- Compatibility I/O
- Serial Communications
- Using Consoles
- Summary
- Chapter 9. Using Serialization with File and Archive Objects
- Part III: Internet Programming with MFC
- Chapter 10. MFC and the Internet Server API (ISAPI)
- Chapter 11. The WinInet API
- Chapter 12. MFC HTML Support
- Part IV: Advanced Programming Topics
- Chapter 13. Using the Standard C++ Library
- Chapter 14. Error Detection and Exception Handling Techniques
- Chapter 15. Debugging and Profiling Strategies
- Chapter 16. Multithreading
- Chapter 17. Using Scripting and Other Tools to Automate the Visual C++ IDE
- Part V: Database Programming
- Chapter 18. Creating Custom AppWizards
- Chapter 19. Database Overview
- Chapter 20. ODBC Programming
- Chapter 21. MFC Database Classes
- Chapter 22. Using OLE DB
- Chapter 23. Programming with ADO
- Part VI: MFC Support for COM and ActiveX
- Chapter 24. Overview of COM and Active Technologies
- Chapter 25. Active Documents
- Chapter 26. Active Containers
- Chapter 27. Active Servers
- Chapter 28. ActiveX Controls
- Part VII: Using the Active Template Library
- Chapter 29. ATL Architecture
- Chapter 30. Creating COM Objects Using ATL
- Chapter 31. Creating ActiveX Controls Using ATL
- Chapter 32. Using ATL to Create MTS and COM+ Components
- Part VIII: Finishing Touches
- Chapter 33. Adding Windows Help
- Part IX: Appendix
File System Overview
Put simply, a file system turns a vast homogenous array of bits in a storage medium into a highly organized hierarchical structure more akin to the human mode of categorically oriented thinking.
A file system also must be fast and efficient, making good use of the underlying technology to provide rapid responses to user requests to retrieve and store data.
Each file system occupies a storage device such as a floppy disk or CD-ROM drive, or an area on a hard drive called a volume. These volumes are labeled with drive names such as A:, B:, C:, D:, and so on.
File systems have evolved to offer many more advanced features, such as long filenames, file security via permissions and ownership, network volume mapping, virtual files, and file/directory compression.
This evolution has led to a number of file-system types. Windows NT supports the largest set of file-system types, providing support for both the latest innovative file systems and the older, simpler types. Windows 98 supports the next-largest set, with Windows 95 and Windows 3.11 bringing up the rear.
Things became more confusing as support for some file-system types was dropped in later versions of the operating system (for example, HPFS was dropped in NT 4.0).
The following sections clarify the various file-system types and operating-system versions that support them.
The FAT File System
The file allocation table (FAT) file system is the simplest of all the file systems and is supported by all Windows operating systems.
The FAT file system (also known as FAT-16) is a leftover from the MS-DOS operating system. As its name suggests, the FAT file system merely stores a table (and a backup table) of all the files and their positions on the disk. The table is stored at the beginning of a disk volume and must be updated whenever files are added or modified. New data is just allocated to slots large enough to contain it, which leads to high fragmentation.
This simplicity leads to poor performance and limited robustness. The maximum size of a FAT file system is 4GB under Windows NT, but performance is seriously degraded for file systems larger than 2GB.
The basic FAT filenames are limited to eight characters, followed by a dot, and then a three-letter suffix. All lowercase letters in filenames are converted to uppercase letters when stored. Longer filenames are truncated and made unique by conversion to a six-character name, followed by a tilde and an autogenerated number to preserve uniqueness.
FAT file systems support only the very basic file attributes (such as read-only, archive, hidden, and system). No security attributes or permissions can be assigned to files on a FAT file system.
It is unusual for modern Windows versions to create pure FAT file systems for their main hard drive partitions. But older systems (including early versions of Windows 95) still may use and preserve FAT file systems. Also, floppy disks still use FAT (protected mode), because it is the common denominator for file interchange and has a small footprint for small volume sizes (such as the common 1.44MB floppy disk standard).
Protected-Mode FAT
Windows NT 3.5 and Windows 95 (and subsequent versions) use a clever trick to preserve long filenames by using several FAT entries to encode each file with a longer filename. These clever tricks are known as the protected-mode FAT and allow filenames of up to 256 characters.
These additional entries are marked with the hidden attribute, so they are invisible when you are browsing the directory entries. This system lets MS-DOS applications see the 8.3 component as normal, but more modern Windows versions can preserve longer names.
The FAT-32 File System
Originally, Windows 95 used the pure FAT file system (FAT-16). This system was very inefficient for the more common larger disk volumes, however, because even a 1-byte file had to consume 32KB of disk space as the cluster size increased.
The FAT-32 file system was introduced with Operating System Release 2 (OSR2) of Windows 95. That system liberates lots of disk space tied up in those large clusters by reducing the cluster size to 4KB (for up to 8GB disk volumes). Unfortunately, the change in cluster size made it difficult for existing Windows 95 users to take advantage of OSR2, as it required a new installation, and could not be applied as an upgrade.
The other big advantage of FAT-32 is the capability to support much larger disk volumes, up to a limit of 2TB (terabytes) or 2,048GB.
Windows 98 supports both FAT-16 and FAT-32 file systems. FAT-16 is used by default, but FAT-32 can deliver more disk space and better performance.
The HPFS File System
The High-Performance File System (HPFS) originated from the OS/2 operating system. It allowed access to larger disk volumes than FAT and filenames of up to 254 characters (and double-byte character sets, such as Unicode, in filenames).
HPFS also allowed flexible attribute information with a block of up to 64KB available for user-defined attributes, but it didn't offer integrated file system–level security.
HPFS provided a large performance increase over the FAT file systems, but performance degraded with larger volume sizes.
Support for HPFS was dropped from Windows NT 4.0 onward, and previous versions of Windows NT didn't support security permissions for HPFS. Windows 95 and 98 do not support HPFS.
The NTFS File System
The New Technology File System (NTFS) was designed with Windows NT to fully support the sophisticated NT security model at a low level (however, lack of file encryption makes this fairly pointless, because the volume can be interrogated freely from other operating systems).
Filenames can contain up to 255 characters and preserve case (although they are not case-sensitive).
The theoretical volume size for NTFS exceeds any existing hardware, allowing volumes of up to 16EB (Exabytes). 16 Exabytes is 264 bytes, or 18,446,744,073,709,551,616 bytes.
NTFS is fast and gives a good scalable performance for file systems with volume sizes of more than 400MB.
Windows 95 and Windows 98 do not support NTFS, but Windows NT (obviously) does.
The CDFS File System
The Compact Disk File System (CDFS) is based on the ISO 9660 Standard (but extends it to allow long and double-byte filenames). To applications, the CDFS file system appears similar to a FAT file system.
Windows 95/98, Windows NT 3.5, and subsequent versions support CDFS.
Networked File Systems and Mapped Volumes
The (modern) Windows family of operating systems (95/98 and NT) was designed with networked file-system sharing from the ground up. Applications can specify filenames that conform to the Universal Naming Convention (UNC), which includes the name of the host machine, the requested volume on that machine, and the path and filename of the target file.
The hostname starts with two backslash characters (\\). The rest of the name then is separated by single backslashes, as in an ordinary pathname.
For example, the UNC name \\thehost\c\thefile.cpp means find the file called thefile.cpp on the volume labeled c on the machine called thehost.
This name is submitted to the Multiple Universal Name Convention Provider (MUP), which attempts to resolve the name and hand the file-access request over to a network redirector (RDR).
The RDR then contacts the host machine and passes the I/O request to the remote networked host machine to handle. The host machine then passes the request to the file system for the specified volume, which then sends any return data back to the calling machine.
You can map one of these UNC names to a virtual volume on your local machine (as you can in Windows Explorer with the Tools/Map Network Drive option).
This mapping assigns a local volume letter to the UNC name and establishes a connection to the remote host machine specified. After this connection is established, your applications can specify the volume name and destination filename without needing the full UNC name. This capability lets applications treat the remote volume as if it were just another local storage device, which is very useful for older UNC-unaware applications.
Suppose that you map \\thehost\c\ as X. You then could access thefile.cpp from your application as simply X:thefile.cpp. Because UNC naming allows subdirectory naming, you also can specify subdirectories to map, which then appear as complete volumes in their own right.
However, for operating systems such as Windows 95 and 98 (which have little in-built security), allowing such freedom of access to a networked machine would have dreadful security implications. Therefore, your local machine can access only remote volumes that have been marked explicitly for sharing by a remote machine. (You can mark these volumes for sharing by using the Sharing context menu option from Windows Explorer.)
Because the host machine implements the actual file-system access, networking allows interaction between normally incompatible file systems and platforms. Windows 95 and 98 operating systems can't access NTFS volumes located on the local machine. However, they can access files on a Windows NT NTFS via shared file systems, because the actual file-system access is performed by the Windows NT host machine.
The DFS File System
A distributed file system (DFS) extends the concept of networked file systems and file mapping so that remote volumes can be mounted on a local file system transparently as subdirectories.
Other operating systems, such as UNIX, have had this design philosophy from their inception. Windows, however, has evolved from the MS-DOS drive name world and was forced by backward-compatibility issues to accept volume mapping by drive letter.
Windows NT Server addresses the problems that drive-letter mapping imposes (such as running out of letters in big networked file systems) by supporting DFS.
Windows NT Workstation and Windows 95/98 platforms can access files over a DFS but only via a Windows NT Server.
DFS provides an excellent mechanism for large organizations to simplify the administration, backup, and virus scanning of a large number of individual PCs by mounting each PC as a subdirectory of an organization-wide network.
File System Compression
Both Windows NT and Windows 95/98 support volume compression, although the technique used differs. Windows 95/98 uses a special format called DriveSpace , whereas Windows NT lets you set a compression attribute against each folder to compress that folder.
Unfortunately, Windows NT cannot access Windows 95/98 FAT file systems that have been compressed with the DriveSpace format (except via network access).
This inability can cause problems on dual-boot machines, so you should avoid compression in these cases.
Compression techniques also carry a performance penalty, depending on the type of compression and the file being accessed.
Disk Quotas
NTFS 5 and later versions (with Windows NT 5.0) will support a technique called disk quotas. This means that administrators will be able to assign specific limits to the amount of disk space available to individual users.
Write functions may fail when users reach their own quota limits, even though sufficient disk space exists on the volume as a whole.
Differences in Functions Among File Systems
The various capabilities and drawbacks of all these different file-system types have implications that reach right down to individual operating system function calls. If you are designing an application that must work on a variety of platforms, you must be aware of these differences and respond to various return and error codes as appropriate.
Large parts of the Application Programming Interface (API) are ignored by lack of file system support, especially in the sophisticated areas of NT security.
Determining the File System and Drive Types
You can determine the file-system type for a volume from within your code by using the GetVolumeInformation() Win32 API function. You can pass the name of a file system's root directory to this function, along with pointers to various buffers, to retrieve lots of information regarding the file system's capabilities and type.
You also can find details about the type of device a particular root path belongs to by passing the root path name to GetDriveType(). The value returned indicates whether the drive is a network drive, a CD-ROM drive, a fixed disk, or another type of technology.
Win32 File Objects | Next Section

Account Sign In
View your cart