fs.dox

linux下开发的针对所有磁盘的数据恢复的源码

/*! \page fspage File Systems

This section describes the general file system analysis concepts and corresponding APIs in TSK.  In addition to this documentation, there are sample programs in the <tt>samples</tt> directory in TSK that show these functions being used while processing a disk image. 

\section fs_gen General Concepts
\subsection fs_layers File System Layers

File systems are a collection of data structures that are stored in a disk or volume that allow you to save and open files. There are many different file systems and they all have unique data structures, but there are some general concepts that apply to all file systems.  These general concepts are used in TSK to provide generic access to a variety of file systems. 

TSK organizes the data in file systems into five categories: File System, Data Units, Metadata, File Name, and Application. All data can be categorized into one of these: 
<ul>
<li>File System Category:  The data in this category describe the layout and general features of the file system.  For example, how big each data unit is and how many data units there are.</li>

<li>Data Unit Category: This category contains the data units (i.e. blocks and clusters) in the file system that can store file content. Data units are a fixed size and most file systems require it to be a power of 2, 1024- or 4096-bytes for example. </li>

<li>Metadata Category: This is where the descriptive data about files and directories are stored. This layer includes the inode structures in UNIX, MFT entries in NTFS, and directory entry structures in FAT. This layer contains information such as last access times, permissions, and pointers to the data units that were allocated by the file or directory. The data in this category completely describes a file, but it is typically given a numeric address that is difficult to remember.</li>

<li>File Name Category: This is where the actual name of the file or directory is saved. In general, this is a different structure than the metadata structure. The exception to this is the FAT file system. File names are typically stored in data structures in the parent directory. The data structures contain a pointer to the metadata structure, which contains the rest of the file information. </li>

<li>Application Category: This is where a bunch of non-essential file system data exists. These are features that make life easier for the file system and operating system. Examples include journals that record file system updates and lists that record what files have recently been updated. </li>
</ul>

A basic ASCII diagram is shown here of the different categories.  The file system category identifies the locations of the file name, metadata, data units, and application categories.  The file names then point to the metadata, and the metadata points to the data units. 
<pre>
                     +-------------------------+
                     |       File System       |
                     +-------------------------+
                       /          |           \        +------------------+
                      /           |            \       |   Application    |
                     /            |             \      +------------------+
                    /             |              \
        +------------+      +-----------+      +-------------+
        | File Names | ---> | Metadata  | ---> | Data Units  |
        +------------+      +-----------+      +-------------+
</pre>

The command line tools and the file system APIs are organized based on these layers.   Data at each layer can be directly accessed and some functions combine layers. 
    
\subsection fs_del Deleted Files

When a file is deleted, its data units, metadata structure, and file name structure are typically marked as being free and they can be reused when a new file is created.  It is very easy for them to be reallocated at different times and therefore care must be taken when interpreting the data associated with deleted files. 

When you encounter an unallocated file name, check the allocation status of the metadata structure it points to.  If the metadata structure is allocated, then either the metadata structure was reallocated to a new file or the the unallocated file name was created when a file was moved and the unallocated name is the old file name.  In general, there is no way to differentiate between these two scenarios (the exception is in NTFS, which includes sequence numbers that increment each time the metadata structure is reallocated). One test that can be applied in this situation is to compare the type (i.e. file or directory) as reported in the file name structure versus the type as reported in the metadata structure. If one is a directory and one is a file, then the metadata structure was reallocated.  You could also compare the file name extension with the file type (i.e. HTML, doc, JPEG). 

When you encounter an unallocated metadata entry, there may no longer be a file name structure that points to it. These are called <b>orphan files</b>.  You will still be able to access them via their metadata address, but the their full path will be unknown.  TSK makes a special directory to store the orphan files in so that they can be easily accessed.  



    \section fs_open Opening the File System
Typically, a file system exists in a \ref vspage "volume", but it can also exist on its own on a disk (such as a USB drive, CD-ROM, or floppy disk).  You may also have an image file that is of only one partition (i.e. a logical image). Because of these different scenarios, TSK has two functions to open a file system.     

The tsk_fs_open_img() function allows you to open a file system using only a TSK_IMG_INFO structure and an offset.  The offset indicates the location where the file system starts in the image. As a convenience, there is also the tsk_fs_open_vol() function that takes a TSK_VS_PART_INFO structure as an argument and determines the offset based on the volume information. 

Both of these functions return a TSK_FS_INFO structure that is used as a handle for more detailed file system analysis.  Close the file system with the tsk_fs_close() function.   The TSK_FS_INFO structure contains data regarding the number of data units, the number of metadata structures, etc. 

    \subsection fs_types File System Types

    The functions that open the file system can detect the file system type, but sometimes you may need to specify it (if for example TSK detects multiple file system structures).   Internally, TSK uses a numerical ID (TSK_FS_TYPE_ENUM) for each file system type, which is stored in TSK_FS_INFO::ftype.  

If you have an TSK_FS_INFO structure and want to know what file system type it is for, you can pass the TSK_FS_INFO::ftype value to one of the TSK_FS_TYPE_ISXXX macros, such as TSK_FS_TYPE_ISNTFS(). 

<pre>
	if (TSK_FS_TYPE_ISNTFS(fs_info->ftype)) {
		....
	}
</pre>

To map from the numerical ID to a short name (such as "ntfs"), the tsk_fs_type_toname() function can be used.  You can also map from the short name to the ID using the tsk_fs_type_toid() function.

    To determine the IDs of the supported file systems, the tsk_fs_type_supported() function can be used.  The names and descriptions of the supported types can be printed to an open FILE handle using the tsk_fs_type_print() function.

 	\subsection fs_read Reading General File System Data
As you will see, there are many ways to access file system data from the different categories. One of the most generic methods is using the tsk_fs_read() function.  It simply takes a byte offset relative to the start of the file system and a buffer to read the data into.  It does not care about block addresses or files.  In the following sections, there are smarter versions of this function that will take block addresses as an argument, instead of a byte offset. 


\section fs_block_open Opening and Reading File System Blocks
TSK allows you to read the contents of any block in the file system. The size of each data unit is defined in the TSK_FS_INFO::block_size field and the number of data units (as defined by the file system) is defined in the TSK_FS_INFO::block_count field.  The address of the first block is defined in TSK_FS_INFO::first_block and the last block address (as defined by the file system structures) is defined in TSK_FS_INFO::last_block.  In some cases, the image may not be complete and the last block that can be read is less than TSK_FS_INFO::last_block.  In that case, TSK_FS_INFO::last_block_act contains the actual last block in the image.  When last_block_act is less than last_block, it means that the image is not complete. 

You can obtain the contents of a specific block by calling the tsk_fs_block_get() function. It returns a TSK_FS_BLOCK structure with the contents of the data unit and flags about its allocation status. You must free the TSK_FS_BLOCK structure by calling tsk_fs_block_free(). 

You can also walk the data units by calling tsk_fs_block_walk().  This function will call a callback function on data units that meet a certain criteria.  Walking is useful if, for example, you want to focus on only allocated or unallocated data units.  

You can also read the contents of a data unit using the tsk_fs_read_block() function, which reads a block of data (given its data unit address) into a buffer.  tsk_fs_read_block() does not provide the data unit's allocation status and is therefore more efficient than tsk_fs_block_get() if you want only the content. 

One FAT file system specific thing should be mentioned here. FAT stores its file content in clusters, but the first cluster does not start at the beginning of the file system.  There is typically many megabytes of data (FAT tables) before it.  If TSK were to use clusters as the standard data unit, it would have no way of addressing the sectors prior to the first cluster and a confusing addressing scheme would need to exist so that all data could be accessed.  For simplicity, TSK uses sector addresses everywhere with FAT file systems. All data unit addresses used by the TSK API are in 512-byte sectors (and TSK_FS_INFO::block_size is 512 and not the original cluster size).  



\section fs_file Opening and Reading Files