CPGuide - File Systems
Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation
An application views a file as a logical sequence of data; OS/2 file systems manage the physical locations of that data on the storage device for the application. The file systems also manage file I/O operations and control the format of the stored information.
Applications use the OS/2 file system functions to open, read, write, and close disk files. File system functions also enable an application to use and maintain the disk that contains the files-the volumes, the directories, and the files on the disks of the computer. Applications also use OS/2 file system functions to perform I/O operations to pipes and to peripheral devices connected to the computer, like the printer.
The following topics are related to the information in this chapter:
- File names
- File management
- Extended attributes
- Device I/O
Contents
About File Systems
A file system is the combination of software and hardware that supports storing information on a storage device. In the OS/2 operating system, the file system specifies how data is organized on the mass storage devices of the computer, such as hard disks and floppy disks.
Each drive is assigned a unique letter to distinguish it from other drives. A single hard disk can also be divided into two or more logical drives. A logical drive represents a portion of the hard disk and, like a physical drive, is assigned a unique letter to distinguish it from other physical and logical drives.
The file system organizes disks into volumes, directories, and files. A volume is the largest file system unit. It represents all the available storage on the logical drive. An optional volume name identifies the volume.
Volumes are subdivided into directories, which contain files and other subdirectories. Each volume has a root directory, which contains file and directory entries. All other subdirectories trace their ancestry back to the root directory. Each directory entry identifies the name, location, and size of a specific file or subdirectory on the disk. A file is one or more bytes of data stored on the disk. Subdirectories provide an additional level of organization and, like the root directory, can contain files and directory entries.
The file system also enables users and applications to access certain non-disk devices as if they were files. An example of such a device would be the printer, which can be accessed through the file system by using the printer's logical name, PRN, as a file name.
Types of File Systems
The OS/2 operating system has two file systems: the file allocation table (FAT) file system and the high performance file system (HPFS). These file systems define how information is organized on the storage devices.
A user can choose to install either or both file systems. An application must be able to work with any file system. The OS/2 operating system provides a common set of file system functions that are not dependent on a particular file system.
Both of these file systems support:
- Existing logical file and directory structure
- Existing naming conventions
- Multiple logical volumes (partitions)
- Multiple and different storage devices
- Redirection or connection to remote file systems
- Extended attributes
- Metacharacter file-name processing.
Additionally, HPFS supports:
- Long file names
- An extendable application interface.
The High Performance File System is an example of a class of file systems called installable file systems. Installable file systems are installed by the user (by changing CONFIG.SYS) and are loaded by the operating system during system initialization.
The OS/2 operating system permits users to have multiple file systems active at the same time; for example a FAT file system for one hard disk and HPFS for another.
FAT File System
The OS/2 FAT file system is based on the DOS FAT file system. This file system, also used in previous releases of the OS/2 operating system and in PC-DOS, controls storage of data files for hard and floppy disks.
The FAT file system is hierarchical, supporting multiple directories on the disk. Each directory can contain one or more files or subdirectories.
The FAT file system uses the 8.3 file name convention. Under this convention, the file name consists of a file name of up to eight characters, a separating period (.), and a file name extension of up to three characters.
Installable File Systems
An installable file system is a file system in which software is installed when the operating system is started. The OS/2 operating system supports installable file systems and permits users to have multiple file systems active at the same time.
Users install a file system by specifying the file system components in the CONFIG.SYS file. The file system software consists of device drivers and dynamic link libraries. The device drivers access storage devices; the dynamic link libraries control the format of information on a device and manage the flow of data to and from the device. The user must use the DEVICE= command to specify the device driver and the IFS= command to specify the dynamic link library.
Installable file system drivers are loaded during system initialization when an IFS= statement is encountered in the CONFIG.SYS file. The operating system loads the device driver and dynamic link library and initializes a specific device for use with a file system.
These file systems can support file and directory structures different from the FAT file system.
An example of an installable file system might be a file system designed specifically for use on a network server. Another example of an installable file system is the High Performance File System (HPFS), which is included with the OS/2 operating system.
High Performance File System
The High Performance File System (HPFS) is an installable file system. It is a hierarchical system and supports multiple directories. In many cases, accessing files under HPFS is faster than accessing similar files under the FAT file system. During installation of the OS/2 operating system, users can install the HPFS on the hard disk they use to start their computer.
Features of HPFS include:
- Caching of directories, data, and file system data structures
- Multi-threaded I/O operations
- Write-behind logic
- Optional write-through
- Strategic allocation of directory structures
- Highly contiguous file allocation
- Enhanced recoverability
- Extended attribute support
- Long file name support
- Starting the OS/2 operating system from an HPFS disk
File names under HPFS can contain 255 characters (one must be the terminating NULL, "\0") and can contain characters that are not valid for the FAT file system-for example, spaces. Each element of a path name residing on an HPFS disk can also have up to 255 characters. The total path including drive, directories, and file name cannot exceed 260 characters (259 with the terminating NULL). For more information on long file name support by installable file systems see Long File Names.
HPFS provides extremely fast access to very large disk volumes. HPFS uses a memory cache divided into blocks of 2KB. Data that is read from and written to the disk is transferred through this cache. Frequently-used data will often be found in the cache, thereby saving the time that a disk-read operation would require. When a user request specifies data that is not present in the cache, HPFS selects the least-recently used discardable block and then fills the block with the requested data.
When a write-data request is received, it usually is not necessary that the data be immediately written to the disk. HPFS will copy such data into the block cache without actually performing the disk-write operation. When the data is in the cache, it is written to disk as a background activity (referred to as lazy writing) which enables the typical user-write operation to occur much faster than in file systems where all write operations are synchronous.
The High Performance File System consists of:
- The High Performance File System driver, HPFS.IFS
- The High Performance File System lazy-write utility, CACHE.EXE
- The High Performance File System lazy-write startup program, STARTLW.DLL
- The High Performance File System utilities, UHPFS.DLL
The user determines the amount of lazy-write support by setting the following parameters on the command line that calls CACHE.EXE:
- MaxAge:
- When the data in a cache block exceeds the specified time the block is queued for writing to the disk. This reduces the amount of data lost due to inopportune system shutdowns.
- DiskIdle and BufferIdle
- When no user I/O request (non-lazy-write) has been made for DiskIdle number of milliseconds, all cache blocks (in oldest-first order) that have not been touched for BufferIdle number of milliseconds are queued for writing to disk. This enables HPFS to write out user data during times of relative disk inactivity and to reduce the need for rewriting heavily used cached blocks.
STARTLW.DLL contains the code that starts the lazy-write thread.
Local and Remote File Systems
Installable file systems work with a variety of storage devices. A file system on a local device such as a disk drive or virtual drive is called a local file system. A file system on a remote device, such as a disk drive on another computer, is called a remote file system. An application can establish a connection to a local or a remote file system by using DosFSAttach.
For a local file system, the operating system uses a block device driver, which accesses disk hardware, to handle input and output to the device. The operating system automatically connects most (if not all) local file systems when it starts. However, an application can attach and detach additional file systems as needed.
For a remote file system, the operating system uses a device driver that typically accesses a communications or network device. Usually, the actual storage device is located on another computer, and the two computers communicate requests and data through a network connection. An application can associate a remote file system with a drive letter by using DosFSAttach. Once the connection is made, the application can access directories and files on the remote device simply by using the assigned drive letter, treating the remote device as if it were on the same computer.
Recognizing DOS and OS/2 File Objects
The OS/2 FAT file system recognizes file objects created by the DOS FAT file system. This means that applications running under the OS/2 operating system (these include both OS/2 applications and DOS applications running in a DOS Session) can access file objects created by applications running under DOS.
Because the OS/2 FAT file system supports the same directory structure as the DOS FAT file system, applications running under DOS can access files and directories created by the OS/2 FAT file system.
However, the High Performance File System (HPFS) does not support the same directory structure as the DOS FAT file system. Therefore, the DOS FAT file system will not recognize file objects created by HPFS. This means that if you start the computer with DOS, applications running under DOS cannot access files and directories on HPFS disks.
DOS applications running in a DOS Session under the OS/2 operating system can recognize files and directories on both FAT and HPFS disks. A request from a DOS Session to read a file on a FAT disk is handled by the OS/2 FAT file system. Similarly, a request from a DOS Session to read a file on an HPFS disk is handled by the OS/2 High Performance File System.
Storage Devices and File Systems
OS/2 file systems store information on mass storage devices. These devices are usually hard disks or floppy diskettes, but can be other media, such as CD-ROM.
Each drive (or device) is assigned a unique letter to distinguish it from other drives. On most personal computers, drive A is the first floppy disk drive, drive B is the second floppy disk drive, drive C is the first hard disk drive, and drive D is the second hard disk drive.
A single hard disk can be divided into two or more partitions, each of which are then viewed as a separate logical drive. A logical drive, like a physical drive, is assigned a unique letter to distinguish it from other physical and logical drives. FDISK is the OS/2 utility used to partition physical storage devices.
A personal computer running the OS/2 operating system can have up to 26 logical disk drives.
Each logical storage device can be managed by a different file system. The file system attached to a storage device manages that device. A user attaches a file system to a storage device by:
- Loading the file system driver during system initialization (by including an IFS= statement in CONFIG.SYS).
- Formatting the storage device by using the format options for the file system.
During installation of the OS/2 operating system, users have the option of formatting hard disks with the FAT file system or with the (HPFS). If the user chooses to use the HPFS, an IFS= statement is added to the CONFIG.SYS file so that HPFS is loaded automatically during each system startup. During formatting, the file system driver is associated with the logical storage device or drive letter of the hard disk.
When an application calls a file system function, the operating system directs the request to:
- The installable file system managing the storage device, or
- The FAT file system, if no installable file system is loaded and attached to the storage device.
The file system used to format the storage media manages that media each time the system is started, as long as the file system is loaded during system start-up. The operating system directs file system requests for a storage media to the file system that formatted the media. If no file system recognizes the format of the media, the OS/2 FAT file system attempts to manage that media. This might occur when the file system used to format the storage media is not loaded during system startup (the IFS= statement was removed from the CONFIG.SYS file after OS/2 installation). If the OS/2 FAT file system cannot recognize the media format (the media might have a different directory structure), the user receives an error when attempting to access the media.
For example, assume a system is configured with diskette drive A and hard disk drives C and D. During OS/2 installation, the user elects to format drive C using HPFS. Drive C is, then, managed by HPFS. Drive D was formatted with the FAT file system, so it is managed by the OS/2 FAT file system, as is diskette drive A (removable media cannot be formatted using HPFS). When an application calls DosOpen to open a file on drive C, the operating system directs the request to HPFS. When an application calls DosOpen to open a file on drive A, the operating system directs the request to the OS/2 FAT file system.
If HPFS is not loaded during system startup, the FAT file system will receive file system requests made for drive C. However, because HPFS supports a different directory structure than the FAT file system does, the OS/2 FAT file system cannot recognize file objects on the disk. The user will receive an error when attempting to gain access to the disk.
Users can determine which file system was used to format a storage device by using the CHKDSK utility. CHKDSK displays a message indicating which file system manages the specified drive. Because DOS does not use extended attributes, a user must use CHKDSK in an OS/2 session rather than in a Dos Session to examine a FAT partition.
File System Utilities
Utilities for each file system are in a single dynamic link library. The utilities that the operating system calls are based on the file system that recognizes the volume on which the utility is to be run. The dynamic link library for each file system has the following utilities:
- FORMAT
- Disk formatter
- CHKDSK
- File system validation and repair
- RECOVER
- File recovery
- SYS
- System installation
OS/2 Boot Manager
The OS/2 Boot Manager enables different operating systems to co-reside on the same computer. The user selects the operating system to boot when the computer is turned on. For example, DOS, AIX, and the OS/2 operating system can co-reside on the same machine. There can also be a previous version of the OS/2 operating system on the machine co-existing with the current version of the operating system.
Each operating system has its own partition and each partition is managed by the appropriate file system for the operating system that owns it. A DOS partition has a FAT file system. An OS/2 partition can have either a FAT file system or HPFS. An AIX partition will use the AIX file system to manage its partition.
- Note
- FAT partitions that follow HPFS partitions on the same physical disk cannot be accessed when using DOS because DOS stops at the first partition it does not recognize.
Using File Systems
In order to take advantage of the capabilities of OS/2 file systems, application developers must be able to manage the file systems.
Most of the file system functions work with either the FAT file system or the High Performance File System (HPFS).
- Note
- In the example code fragments that follow, error checking was left out to conserve space. Applications should always check the return code that the functions return. Control Program functions return an APIRET value. A return code of 0 indicates success. If a non-zero value is returned, an error occurred.
Attaching and Detaching File Systems
A file system driver that uses a block device driver for I/O operations to a local or remote (virtual disk) device is called a local file system. A file system driver that accesses a remote system without a block device driver is called a remote file system.
An application, typically a network application, can call DosFSAttach to:
- Attach a drive to a remote file system
- Detach a drive from a remote file system
- Attach a pseudocharacter device name to a local or remote file system
- Detach a pseudocharacter device name from a local or remote file system.
DosFSAttach establishes or breaks the connection between a drive or device and a file system. If an attachment is successful, all requests to that drive or name are routed to the specified file system. If a detachment is successful, the operating system will no longer recognize the drive or name in a file system call.
DosFSAttach does not support:
- Redirection of drive letters representing local drives
- Attachment to drives or devices that are not in the system's name space. (DosFSCtl can be used to attach to drives or devices not in the system's name space.)
A name space is a set of names that are known to the file system. For example, CON (console) and PRN (printer) are always in the OS/2 file system's name space.
The following code fragment attaches a drive to a remote file system driver (FSD). Assume that the FSD does not require any user-supplied data arguments.
#define INCL_DOSFILEMGR /* File System values */
#include <os2.h>
#include <stdio.h>
#include <string.h>
UCHAR ucDeviceName[8]; /* Device name or drive letter string */
UCHAR ucFSDName[40]; /* FSD name */
PVOID pDataBuffer; /* Attach argument data */
ULONG ulDataBufferLen; /* Buffer length */
ULONG ulOpFlag; /* Attach or detach */
APIRET ulrc; /* Return code */
strcpy(ucDeviceName,"Y:");
/* Drive letter with which to attach the */
/* file system driver */
strcpy(ucFSDName,"\\lan03\\src");
pDataBuffer = 0; /* Assume that no user-supplied data */
/* arguments are required */
ulDataBufferLen = 0; /* No data buffer supplied */
ulOpFlag = 0; /* Indicate Attach request */
ulrc = DosFSAttach(ucDeviceName,
ucFSDName,
pDataBuffer,
ulDataBufferLen,
ulOpFlag);
if (ulrc != 0) {
printf("DosFSAttach error: return code = %ld", ulrc);
return;
}
Obtaining Information about an Attached File System
To obtain information about block devices, and all character and pseudocharacter devices, including the type of device and the name of the file system driver the device is attached to, use DosQueryFSAttach.
The information can be used to determine if the operating system recognizes that a particular file system is attached to a storage device. This is important to an application that must guarantee such a state. An application of this type must handle the situation where the file system driver that formatted a certain disk was not loaded during system startup. (The user might have omitted the IFS= statement in the CONFIG.SYS. file). In such a situation, the data on the disk could be destroyed because the wrong file system was attached to the disk by default.
The following code fragment returns information about an attached file system.
#define INCL_DOSFILEMGR /* File System values */
#include <os2.h>
#include <stdio.h>
#include <string.h>
UCHAR ucDeviceName[8]; /* Device name or drive letter */
/* string */
ULONG ulOrdinal; /* Ordinal of entry in name list */
ULONG ulFSAInfoLevel; /* Type of attached FSD data */
/* required */
FSQBUFFER2 fsqDataBuffer; /* Returned data buffer */
ULONG ulDataBufferLen; /* Buffer length */
APIRET ulrc; /* Return code */
strcpy(ucDeviceName,
"Y:"); /* Logical drive of the attached file system */
ulFSAInfoLevel = 1;
ulDataBufferLen = sizeof(FSQBUFFER2); /* Data buffer length */
ulrc = DosQueryFSAttach(ucDeviceName,
ulOrdinal,
ulFSAInfoLevel,
&fsqDataBuffer,
&ulDataBufferLen);
if (ulrc != 0) {
printf("DosQueryFSAttach error: return code = %ld", ulrc);
return;
}
In this example, information was requested about the drive whose name was specified within the DeviceName variable. After the DosQueryFSAttach call, the DataBuffer structure contained a set of information describing the specified attached file system, and the DataBufferLen variable contained the size of information within the structure.
Obtaining Information about a File System
An application can retrieve information about the file system on a given drive by using DosQueryFSInfo. The file system information includes information on the amount of free storage space on the disk. The storage space is given in number of allocation units (clusters) on the disk. Each cluster has an associated number of sectors; each sector contains a given number of bytes. A typical disk has 512 bytes for each sector and 4 sectors for each cluster. DosSetFSInfo enables an application to change the volume identifier for the disk in the given drive.
The following code fragment obtains information about the file system that is associated with a particular logical drive.
#define INCL_DOSFILEMGR /* File System values */
#include <os2.h>
#include <stdio.h>
ULONG ulDriveNumber; /* Drive number */
ULONG ulFSInfoLevel; /* File system data required */
UCHAR ucFSInfoBuf[40]; /* File system info buffer */
ULONG ulFSInfoBufSize; /* File system info buffer size */
APIRET ulrc; /* Return code */
ulDriveNumber = 3; /* Specify drive C */
ulFSInfoLevel = FSIL_ALLOC; /* Indicate that file system allocation */
/* information is requested */
ulFSInfoBufSize = 40; /* Size of return data buffer */
ulrc = DosQueryFSInfo(ulDriveNumber,
ulFSInfoLevel,
ucFSInfoBuf,
ulFSInfoBufSize);
if (ulrc != 0) {
printf("DosQueryFSInfo error: return code = %ld", ulrc);
return;
}
In this example, the data buffer FSInfoBuf is used to receive information about space allocation within the specified file system.
Obtaining Information about a File
An application can retrieve and set information about a specific file by using DosQueryFSInfo and DosSetFileInfo. File information consists of the dates and times that the file was created, last accessed, and last written to (only the time and date the file was last written to are given for FAT partitions); the size (in bytes) of the file; the number of sectors (or clusters) the file occupies; and the file attributes.
The following code fragment obtains file information for a specified file. The example obtains the Level 1 information set for the file. The Level 1 information set for a file includes the dates and times of creation, last access, and last writing. It also includes information about the size of the file and the file's standard attributes. Assume that the handle of the desired file has been placed into FileHandle already.
#define INCL_DOSFILEMGR /* File System values */
#include <os2.h>
#include <stdio.h>
HFILE hfFileHandle; /* File handle */
ULONG ulFileInfoLevel; /* Level of file info required */
FILESTATUS3 fsFileInfoBuf; /* File info buffer */
ULONG ulFileInfoBufSize; /* File data buffer size */
APIRET ulrc; /* Return code */
ulFileInfoLevel = 1; /* Indicate that Level 1 information is desired */
fsFileInfoBufSize = sizeof(FILESTATUS3);
/* Size of the buffer that will */
/* receive the Level 1 information */
ulrc = DosQueryFileInfo(hfFileHandle,
ulFileInfoLevel,
&fsFileInfoBuf,
ulFileInfoBufSize);
if (ulrc != 0) {
printf("DosQueryFileInfo error: return code = %ld", ulrc);
return;
}
In this example, Level 1 file information is placed into the FileInfoBuf buffer.
Communicating with a File System
An extended standard interface between an application and a file system driver is provided by DosFSCtl. This function is similar to DosDevIOCtl, which provides a standard interface between an application and a device driver. An application sends a request to the file system driver by specifying a particular function code. Data is exchanged through data areas and parameter lists.
DosFSCtl can be used to establish open connections to file system drivers that are not attached to a name in the operating system's name space. (A name space is a set of names that are known to the file system. For example, CON and PRN are always in the OS/2 file system's name space.)
The following code fragment demonstrates how a process can communicate with a file system driver (FSD). Assume that the calling process has placed an appropriate file handle into FileHandle. Assume that the specified file system recognizes a function code of hex 8100, and that the function code accepts an ASCII string as input, requires no specific command parameter list, and returns a string of ASCII characters to the caller.
#define INCL_DOSFILEMGR /* File System values */
#include <os2.h>
#include <stdio.h>
#include <string.h>
UCHAR ucDataArea[100]; /* Data area */
ULONG ulDataLengthMax; /* Max. length of Data area */
ULONG ulDataLengthInOut; /* Data area length, in and out */
PVOID pParmList; /* Parameter list */
ULONG ulParmLengthMax; /* Max. length of Parameter list */
ULONG ulParmLengthInOut; /* Parameter list length, in and out */
ULONG ulFunctionCode; /* Function code */
PSZ pszRouteName; /* Path or FSD name */
HFILE hfFileHandle; /* File handle */
ULONG ulRouteMethod; /* Method for routing */
APIRET ulrc; /* Return code */
ulFunctionCode = 0x8100; /* Indicate the function to request */
/* of the file system */
strcpy(ucDataArea,
"PARM1: 98"); /* ASCII string to pass to file system */
ulDataLengthMax = 100; /* Tell the file system the maximum */
/* amount of data it can return */
ulDataLengthInOut = strlen(ucDataArea);
/* On input, this is the number of */
/* bytes sent to the file system */
pParmList = 0; /* In this example, assume that no */
ulParmLengthMax = 0; /* specific command parameter list */
ulParmLengthInOut = 0; /* is required by the file system */
/* for this function code */
ulRouteMethod = 1; /* Indicate that the file handle */
pszRouteName = 0; /* directs routing (this implies */
/* that the RouteName variable is */
/* unused in this example) */
ulrc = DosFSCtl(ucDataArea,
ulDataLengthMax,
&ulDataLengthInOut,
pParmList,
ulParmLengthMax,
&ulParmLengthInOut,
ulFunctionCode,
pszRouteName,
hfFileHandle,
ulRouteMethod);
if (ulrc != 0) {
printf("DosFSCtl error: return code = %ld", ulrc);
return;
}
In this example, the the DataArea buffer is used to store the ASCII string sent by the file system in response to the function request, and the DataLengthInOut variable is used to store the number of bytes placed in the buffer by the file system.
Preparing File Systems for System Shutdown
At any time during normal system operation, data destined for a disk might be in a cache. If this information is not written to disk before the system powered-off, the disk can become corrupted. To prevent this, applications call DosShutdown to ensure that the operating system writes the data in the cache to the disk and prevents any further data from being cached. The user can then safely power-off the system.
- Note
- This call prepares all file systems and device drivers for system shutdown. Therefore, it must be called only when system shutdown is about to occur. The user and applications will no longer have access to their storage devices.
The following code fragment locks out changes to all file systems, and writes system buffers to the disk in preparation for turning off power to the system.
#define INCL_DOSFILEMGR /* File System values */
#include <os2.h>
#include <stdio.h>
ULONG ulReserved; /* Reserved, must be zero */
APIRET ulrc; /* Return code */
ulReserved = 0; /* Reserved, must be set to zero */
ulrc = DosShutdown(ulReserved);
if (ulrc != 0) {
printf("DosShutdown error: return code = %ld", ulrc);
return;
}
Writing Cache Buffers
DosResetBuffer is used to write to disk (flush) the file system's cache buffers for a specific file handle. When called with a value of hex FFFF for the file handle, DosResetBuffer writes all files belonging to the requesting process to disk (this usage should be administered with care, so the user is not burdened with insertion and removal of a large number of removable media volumes).
When DosResetBuffer is called for single file handle, the directory entry for the file is updated as if the file had been closed. However, the file remains open.
DosResetBuffer can also be called with the name of a named pipe. The process that calls DosResetBuffer is blocked at one end of the pipe until all data it has written has been successfully read by the process at the other end of the pipe. This enables communicating processes to synchronize their dialogs.
The following code fragment opens a file, writes some data to the file's buffer, then writes the file's system buffer to the disk.
#define INCL_DOSFILEMGR /* File Manager values */
#define INCL_DOSERRORS /* DOS Error values */
#include <os2.h>
#include <stdio.h> /* Needed for printf */
#include <string.h> /* Needed for strcpy */
int main( USHORT argc, PCHAR argv[] ) {
HFILE hfFileHandle = 0L; /* Handle for file being manipulated */
ULONG ulAction = 0; /* Action taken (returned by DosOpen) */
ULONG ulWrote = 0; /* Number of bytes written by DosWrite */
APIRET ulrc = NO_ERROR; /* Return code */
UCHAR uchFileName[20] = "MYDATA.DAT", /* Name of file */
uchFileData[100] = " "; /* Data to write to file */
/* Open the file MYDATA.DAT. If the file already exists, replace it.
If the file doesn't exist, create it. */
ulrc = DosOpen(uchFileName, /* Path and file name */
&hfFileHandle, /* File handle */
&ulAction, /* Action taken (returned) */
100L, /* File primary allocation */
FILE_ARCHIVED |
FILE_NORMAL, /* File attributes */
OPEN_ACTION_CREATE_IF_NEW |
OPEN_ACTION_REPLACE_IF_EXISTS, /* Open function type */
OPEN_SHARE_DENYREADWRITE |
OPEN_ACCESS_READWRITE, /* Open mode of the file */
0L); /* No extended attributes */
if (ulrc != NO_ERROR) {
printf("DosOpen error: return code = %u\n", ulrc);
return 1;
}
strcpy (uchFileData,
"Data...."); /* This data will be written to file */
ulrc = DosWrite (hfFileHandle, /* File handle */
(PVOID) uchFileData, /* String to be written */
sizeof (uchFileData), /* Size of string to be written */
&ulWrote); /* Bytes written (returned) */
if (ulrc != NO_ERROR) {
printf("DosWrite error: return code = %u\n", ulrc);
DosClose(hfFileHandle); /* close the file */
return 1;
}
ulrc = DosResetBuffer(hfFileHandle);
if (ulrc != NO_ERROR) {
printf("DosResetBuffer error: return code = %u\n", ulrc);
DosClose(hfFileHandle); /* close the file */
return 1;
}
DosClose(hfFileHandle); /* close the file */
return NO_ERROR;
}
