The File and Directory Classes

The File and Directory utility classes expose many static methods for manipulating, surprisingly enough, files and directories. These methods make it possible to move files, query and update attributes, and create FileStream objects. As you learned in Chapter 8, static methods can be called on classes without having to create instances of them.

Some of the most useful static methods of the File class are shown in the Table 18.2.

Some useful static methods of the Directory class are shown in Table 18.3.

The three EnumerateXxx() methods provide better performance than their GetXxx() counterparts when a large amount of files or directories exist.

The FileInfo Class

Unlike the File class, the FileInfo class is not static and does not have static methods. This class is useful only when instantiated. A FileInfo object represents a file on a disk or a network location, and you can create one by supplying a path to a file:

FileInfo aFile = new FileInfo(@"C:Log.txt");

You can also pass the name of a directory to the FileInfo constructor, although in practical terms that isn't particularly useful. Doing this causes the base class of FileInfo, which is FileSystemInfo, to be initialized with all the directory information, but none of the FileInfo methods or properties relating specifically to files will work.

Many of the methods exposed by the FileInfo class are similar to those of the File class, but because File is a static class, it requires a string parameter that specifies the file location for every method call. Therefore, the following calls do the same thing:

FileInfo aFile = new FileInfo("Data.txt");
if (aFile.Exists)
   WriteLine("File Exists");
if (File.Exists("Data.txt"))
   WriteLine("File Exists");

In this code, a check is made to see whether the file Data.txt exists. Note that no directory information is specified here, which means that the current working directory is the only location examined. This directory is the one containing the application that calls this code. You'll look at this in more detail a little later, in the section “Path Names and Relative Paths.”

Most of the FileInfo methods mirror the File methods in this manner. In most cases it doesn't matter which technique you use, although the following criteria can help you to decide which is more appropriate:

• It makes sense to use methods on the static File class if you are making only a single method call — the single call will be faster because the .NET Framework won't have to go through the process of instantiating a new object and then calling the method.
• If your application is performing several operations on a file, then it makes more sense to instantiate a FileInfo object and use its methods — this saves time because the object will already be referencing the correct file on the file system, whereas the static class has to find it every time.

The FileInfo class also exposes properties relating to the underlying file, some of which can be manipulated to update the file. Many of these properties are inherited from FileSystemInfo, and thus apply to both the FileInfo and DirectoryInfo classes. The properties of FileSystemInfo are shown in Table 18.4.

The properties specific to FileInfo are shown in Table 18.5.

The DirectoryInfo Class

The DirectoryInfo class works exactly like the FileInfo class. It is an instantiated object that represents a single directory on a machine. Like the FileInfo class, many of the method calls are duplicated across Directory and DirectoryInfo. The guidelines for choosing whether to use the methods of File or FileInfo also apply to DirectoryInfo methods:

• If you are making a single call, use the static Directory class.
• If you are making a series of calls, use an instantiated DirectoryInfo object.

The DirectoryInfo class inherits most of its properties from FileSystemInfo, as does FileInfo, although these properties operate on directories instead of files. There are also two DirectoryInfo-specific properties, shown in Table 18.6.

Path Names and Relative Paths

When specifying a path name in .NET code, you can use absolute or relative path names. An absolute path name explicitly specifies a file or directory from a known location — such as the C: drive. An example of this is C:WorkLogFile.txt — this path defines exactly where the file is, with no ambiguity.

Relative path names are relative to a starting location. By using relative path names, no drive or known location needs to be specified. You saw this earlier, where the current working directory was the starting point, which is the default behavior for relative path names. For example, if your application is running in the C:DevelopmentFileDemo directory and uses the relative path LogFile.txt, the file references would be C:DevelopmentFileDemoLogFile.txt. To move “up” a directory, the .. string is used. Thus, in the same application, the path ..Log.txt points to the file C:DevelopmentLog.txt.

As shown earlier, the working directory is initially set to the directory in which your application is running. When you are developing with Visual Studio, this means the application is several directories beneath the project folder you created. It is usually located in ProjectNameinDebug. To access a file in the root folder of the project, then, you have to move up two directories with ..... You will see this happen often throughout the chapter.

Should you need to, you can determine the working directory by using Directory.GetCurrentDirectory(), or you can set it to a new path by using Directory.SetCurrentDirectory().

Classes for Using Streams

The classes for using streams are contained in the same System.IO namespace along with the File and Directory classes. These classes are listed in Table 18.7.

Let's look now at how to use each of these classes.

The FileStream Object

The FileStream object represents a stream pointing to a file on a disk or a network path. Although the class does expose methods for reading and writing bytes from and to the files, most often you will use a StreamReader or StreamWriter to perform these functions. That's because the FileStream class operates on bytes and byte arrays, whereas the Stream classes operate on character data. Character data is easier to work with, but certain operations, such as random file access (access to data at some point in the middle of a file), can be performed only by a FileStream object. You'll learn more about this later in the chapter.

There are several ways to create a FileStream object. The constructor has many different overloads, but the simplest takes just two arguments: the filename and a FileMode enumeration value:

FileStream aFile = new FileStream(filename, FileMode.<Member>);

The FileMode enumeration has several members that specify how the file is opened or created. You'll see the possibilities shortly. Another commonly used constructor is as follows:

FileStream aFile =
new FileStream(filename, FileMode.<Member>, FileAccess.<Member>);

The third parameter is a member of the FileAccess enumeration and is a way of specifying the purpose of the stream. The members of the FileAccess enumeration are shown in Table 18.8.

Attempting to perform an action other than that specified by the FileAccess enumeration member will result in an exception being thrown. This property is often used as a way to vary user access to the file based on the user's authorization level.

In the version of the FileStream constructor that doesn't use a FileAccess enumeration parameter, the default value is used, which is FileAccess.ReadWrite.

The FileMode enumeration members are shown in Table 18.9. What actually happens when each of these values is used depends on whether the filename specified refers to an existing file. Note that the entries in this table refer to the position in the file that the stream points to when it is created, a topic you'll learn more about in the next section. Unless otherwise stated, the stream points to the beginning of a file.

Both the File and FileInfo classes expose OpenRead() and OpenWrite() methods that make it easier to create FileStream objects. The first opens the file for read-only access, and the second allows write-only access. These methods provide shortcuts, so you do not have to provide all the information required in the form of parameters to the FileStream constructor. For example, the following line of code opens the Data.txt file for read-only access:

FileStream aFile = File.OpenRead("Data.txt");

The following code performs the same function:

FileInfo aFileInfo = new FileInfo("Data.txt");
FileStream aFile = aFileInfo.OpenRead();

aFile.Seek(8, SeekOrigin.Begin);

aFile.Seek(2, SeekOrigin.Current);

aFile.Seek(-5, SeekOrigin.End);

The StreamWriter Object

Working with arrays of bytes is not most people's idea of fun — having worked with the FileStream object, you might be wondering whether there is an easier way. Fear not, for once you have a FileStream object, you will usually create a StreamWriter or StreamReader and use its methods to manipulate the file. If you don't need the capability to change the file pointer to any arbitrary position, these classes make working with files much easier.

The StreamWriter class enables you to write characters and strings to a file, with the class handling the underlying conversions and writing to the FileStream object for you.

There are many ways to create a StreamWriter object. If you already have a FileStream object, then you can use it to create a StreamWriter:

FileStream aFile = new FileStream("Log.txt", FileMode.CreateNew);
StreamWriter sw = new StreamWriter(aFile);

A StreamWriter object can also be created directly from a file:

StreamWriter sw = new StreamWriter("Log.txt", true);

This constructor takes the filename and a Boolean value that specifies whether to append to the file or create a new one:

• If this is set to false, then a new file is created or the existing file is truncated and then opened.
• If it is set to true, then the file is opened and the data is retained. If there is no file, then a new one is created.

Unlike creating a FileStream object, creating a StreamWriter does not provide you with a similar range of options — other than the Boolean value to append or create a new file, you have no option for specifying the FileMode property as you did with the FileStream class. Nor do you have an option to set the FileAccess property, so you will always have read/write privileges to the file. To use any of the advanced parameters, you must first specify them in the FileStream constructor and then create a StreamWriter from the FileStream object, as you do in the following Try It Out.

The StreamReader Object

Input streams are used to read data from an external source. Often, this will be a file on a disk or network location, but remember that this source could be almost anything that can send data, such as a network application or even the Console.

The StreamReader class is the one that you will be using to read data from files. Like the StreamWriter class, this is a generic class that can be used with any stream. In the next Try It Out, you again construct it around a FileStream object so that it points to the correct file.

StreamReader objects are created in much the same way as StreamWriter objects. The most common way to create one is to use a previously created FileStream object:

FileStream aFile = new FileStream("Log.txt", FileMode.Open);
StreamReader sr = new StreamReader(aFile);

Like StreamWriter, the StreamReader class can be created directly from a string containing the path to a particular file:

StreamReader sr = new StreamReader("Log.txt");

StreamReader sr = new StreamReader(aFile);
int charCode;
charCode = sr.Read();
while(charCode != -1)
{
   Write(Convert.ToChar(charCode));
   charCode = sr.Read();
}
sr.Close();

StreamReader sr = new StreamReader(aFile);
line = sr.ReadToEnd();
WriteLine(line);
sr.Close();

foreach (string alternativeLine in File.ReadLines("Log.txt"))
   WriteLine(alternativeLine);

Asynchronous File Access

Sometimes — for example, when you are performing a lot of file access operations in one go or are working with very large files — reading and writing file system data can be slow. If this is the case, you might want to perform other operations while you wait. This is especially important with desktop applications, where you want your application to remain responsive to users while you are doing work in the background.

To facilitate this, .NET 4.5 introduced asynchronous ways to work with streams. This applies to the FileStream class, as well as to StreamReader and StreamWriter. If you have browsed through the definitions of these classes, you might have noticed some methods that end with the suffix Async — for example, StreamReader has a method called ReadLineAsync(), which is an asynchronous version of ReadLine(). These methods are designed to be used with the task-based asynchronous programming model.

Asynchronous programming is an advanced technique that isn't covered in detail in this book. However, if asynchronous file system access is something you are interested in doing then this is the place to start. You might also want to read Professional C# 5.0 and .NET 4.5.1 by Christian Nagel, Jay Glynn, and Morgan Skinner (Wrox, 2014) for more details.

Reading and Writing Compressed Files

Often when dealing with files, quite a lot of space is used up on the hard disk. This is particularly true for graphics and sound files. You've probably come across utilities that enable you to compress and decompress files, which are handy when you want to move them around or e-mail them. The System.IO.Compression namespace contains classes that enable you to compress files from your code, using either the GZIP or Deflate algorithm — both of which are publicly available and free for anyone to use.

There is a little bit more to compressing files than just compressing them, though. You've probably seen how commercial applications enable multiple files to be placed in a single compressed file, often called an archive. There are classes in the System.IO.Compression namespace that enable similar functionality. However, to keep things simple for this book you'll just look at one scenario: saving text data to a compressed file. You are unlikely to be able to access this file in an external utility, but the file will be much smaller than its uncompressed equivalent!

The two compression stream classes in the System.IO.Compression namespace that you'll look at here, DeflateStream and GZipStream, work very similarly. In both cases, you initialize them with an existing stream, which, in the case of files, will be a FileStream object. After this you can use them with StreamReader and StreamWriter just like any other stream. All you need to specify in addition to that is whether the stream will be used for compression (saving files) or decompression (loading files) so that the class knows what to do with the data that passes through it. This is best illustrated with the following example.