Youwill notice from the previous list that two classes are used to represent a folder and two classes are used to represent a file, which one of these classes you use depends largely on how many times you need to access that folder or file:
¤ Directory and File contain only static methods and are never instantiated. You use these classes by supplying the path to the appropriate file system object whenever you call a member method.
If you want to do only one operation on a folder or file, using these classes is more efficient because it saves the overhead of instantiating a .NETclass.
¤ Directorylnfo and Fiielnfo implement roughly the same public methods as Directory and File, as well as some public properties and constructors, but they are stateful and the members of these classes are not static, You need to instantiate these classes before each instance is associated with a particular folder or file, This means that these classes are more efficient if you are performing multiple operations using the same object.
That’s because they read in the authentication and other information for the appropriate file system object on construction, and then do not need to read that information again, no matter how many methods and so on you call against each object (class instance).
In comparison, the corresponding stateless classes need to check the details of the file or folder again with every method you call.
In this section, you will be mostly’ using the Filelnfo and Directorylnfo classes, but it so happens that many (though not all) of the methods called implemented by File and Directory (although in those cases these methods require an extra parameter – the path name of the file system object; also, a couple of the methods have slightly different names). For example:
Filelnfo myFile = new Filelnfo(@”C:\Program Files\My program\ReadMe.txt”);
has the same effect as:
File.Copy(@”C:\Program Files\My Program\ReadMe.txt”, @”O:\Copies\ReadMe.txt”);
The first code snippet will take slightly longer to execute because of the need to instantiate a Filelnfo object, myFile, but it leaves myFile ready for you to perform further actions on the same file.
By using the second example, there is no need to instantiate an object to copy the file.
You can instantiate a Filelnfo or Directorylnfo class by passing to the constructor a string containing the path to the corresponding file system object.
Youhave just seen the process for a file.
For a folder, the code looks similar:
Directorylnfo myFolder = new Directorylnfo(@”C:\Program Files”);
If the path represents an object that does not exist, an exception will not be thrown at construction, but will instead be thrown the first time that you call a method that actually requires the corresponding file system object to be there.
You can find out whether the object exists and is of the appropriate type by checking the Exists property, which is implemented by both of these classes:
Filelnfo test = new Filelnfo(@”C:\Windows”);
Note that for this property to return true, the corresponding file system object must be of the appropriate type.
In other words, if you instantiate a File Info object supplying the path of a folder, or you instantiate a DirectoryInfo object, giving it the path of a file, Exists will have the value false.
Most of the properties and methods of these objects will return a value if possible – they won’t necessarily throw an exception just because the wrong type of object has been called, unless they are
asked to do something that really is impossible.
For example, the preceding code snippet might first display false (because C: \Windows is a folder). However, it still displays the time the folder was created because a folder still has that information.
But if you tried to open the folder as if it were a file, using the FileInfo.
Open() method, you’d get an exception.
After you have established whether the corresponding file system object exists, you can (if you are using the FileInfo or DirectoryInfo class) find out information about it using the properties in the following table.
Time file or folder was created
DirectoryName (FileInfo only)
Full path name of the containing folder
Parent (DirectoryInfo only)
The parent directory of a specified subdirectory
Whether file or folder exists
Extension of the file; returns blank for folders
Full path name of the file or folder
Tune file or folder was last accessed
Tune file or folder was last modified
Name of the file or folder
Root (DirectoryInfo only)
The root portion of the path
Length (FileInfo only)
The size of the file in bytes
You can also perform actions on the file system object using the methods in the following table.
Create ( ) Creates a folder or empty file of the given name. For a FileInfo this also returns a stream object to let you write to the file.
(Streams are covered later in the chapter.).
Delete ( ) Deletes the file or folder. For folders, there is an option for the Delete to be recursive.
MoveTo( ) Moves and/or renames the file or folder.
CopyTo( ) (FileInfo only) Copies the file. Note that there is no copy method for folders.
If you are copying complete directory trees you will need to individually copy each fileand create new folders corresponding to the old folders.
GetDirectories( ) (DirectoryInfo only) Returns an array of DirectoryInfo objects representing all folders contained in this folder.
GetFiles ( ) (DirectoryInfo only) Returns an array of FileInfo objects representing all files contained in this folder.
GetFileSystemInfos( ) (DirectoryInfo only) Returns FileInfo and DirectcryInfo objects representing all objects contained in this folder, as an array of FileSystemInfo references.
Note that these tables list the main properties and methods and are not intended to be exhaustive.
The preceding tables do not list most of the properties or methods that allow you to write to’or read the data in files.
This is actually done using stream objects, which are covered later in this chapter.
File Info also implements a number of methods, Open ( ), OpenRead ( ), OpenText-(), OpenWrite (), Create ( ), and CreateText ( ), that return stream objects for this purpose.
Interestingly, the creation time, last access time, and last write time are all writable:
// displays the creation time of a file,
// then changes it and displays it again
Filelnfo test = new Filelnfo(@”C:\MyFile.txt”);
test.CreationTime = new DateTime(2008, 1, 1, 7, 30, 0);
Running this application produces results similar to the following:
2/5/2007 2:59:32 PM
1/1/2008 7:30:00 AM
Being able to manually modify these properties might seem strange at first, but it can be quite useful.
For example, if you have a program that effectively modifies a file by simply reading it in, deleting it, and creating a new file with the new contents, you would probably want to modify the creation date to match the original creation date of the old file.