/usr/share/doc/partimage-doc/html/index-5.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
 <TITLE>The PartImage Handbook: Partition Image Internals</TITLE>
 <LINK HREF="index-6.html" REL=next>
 <LINK HREF="index-4.html" REL=previous>
 <LINK HREF="index.html#toc5" REL=contents>
</HEAD>
<BODY>
<A HREF="index-6.html">Next</A>
<A HREF="index-4.html">Previous</A>
<A HREF="index.html#toc5">Contents</A>
<HR>
<H2><A NAME="s5">5.</A> <A HREF="index.html#toc5">Partition Image Internals</A></H2>

<H2><A NAME="ss5.1">5.1</A> <A HREF="index.html#toc5.1">Note about the NTFS support</A>
</H2>



<H3>Note for users</H3>

<P>The NTFS file system is very complex (system files are implemented as regular files).
For this reason it is not fully supported in Partition Image. It mean that you can have problems
when trying to save an NTFS partition, if your system files are very fragmented, or are not
written in standards location. Then, you will have a warning at the beginning of the operation:
<B>The NTFS support is experimental</B>.</P>
<P>But in most cases, it will work without any problem. The best thing to do is to try to save
your NTFS partition. If you have an error message, then you will have to stop. If there was
no error, you can continue. If you can save the partition, you won't have problem when trying
to restore (except if there is a bug).</P>

<H3>Details for developers</H3>

<P>The only difficulty we have with adding NTFS support to Parititon Image is that the
$Bitmap system file is difficult to read. In deed, all system files as the
$MFT, $Bitmap, ... are written on the disk as regulars files. Then, to read
the bitmap, all the code need to read files need to be implemented.</P>
<P>$Bitmap is a file that contains a map of bits. Each cluster of the NTFS partition
can be used or free. There is a bit in the bitmap for each cluster. The bit
is 0 if the cluster is free and is 1 if the cluster is used.</P>
<P>Partition Image need to read the bitmap to know what clusters are used. Then,
it is possible to copy only used clusters of the partition.</P>
<P>With the boot sector, we can read the FILE RECORD of the $MFT. We must then
read the FILE RECORD of the $Bitmap file. But now, we only read this record
at a constant position, which may be false if the MFT was fragmented.</P>
<P>1) First problem: how to have the position of the File Record of the $Bitmap file ?</P>
<P>Then, if we have this file record, we can check the file name, and read the run
list, to know what clusters contains the bitmap data. But we have another problem:
If the $bitmap is very fragmented, the run list cannot be written in the base
file record. Then we must use the "attribute list" to have another run lists...</P>
<P>2) Second problem: how to read the "attribute list" to be able to read all clusters
which contains the $bitmap data...</P>
<P>Without the $Bitmap file, we must save all clusters, even the free ones... That's
not a good way.</P>
<P>3) Another problem is the compression: what to do if the $bitmap file is compressed ?</P>

<H2><A NAME="ss5.2">5.2</A> <A HREF="index.html#toc5.2">The 2 GB file limitation</A>
</H2>

<P>The linux 2.2 kernel does not support files larger than 2 GB, so the size of your image
must not exceed this limit. You can solve this problem using the 2.4 kernel, which doesn't
have this limitation. You can also split your image into small files (of 1,9 GB for example).
You also require a recent glibc version: 2.2 or newer.</P>

<H2><A NAME="ss5.3">5.3</A> <A HREF="index.html#toc5.3">How are the partitions read/written</A>
</H2>

<P>Partition Image use a low level implementation. It mean that Partition Image makes a block/cluster
copy, when saving/restoring data. It read and write physical blocks of the partition. It doesn't use
the linux kernel (file systems support) to read data. It has many advantages:</P>
<P>
<UL>
<LI>Dumping is fast, because there is no need to seek between indexes (FAT, inode table, ...) and files contents. No seek
between blocks when a file is fragmented.</LI>
<LI>It really copies all the data of the file system: files contents, boot sector, inodes, ... Absolutely no
modification can be made while saving/restoring</LI>
<LI>It keeps the file locations. For example, the location of your kernel image will be kept, and LILO won't fail
after you restore your partition.</LI>
</UL>
</P>
<P>But with this method, all files systems support must be implemented, and it's difficult to resize the partition
when restoring. It is also impossible to extract a file from an image.</P>

<H2><A NAME="ss5.4">5.4</A> <A HREF="index.html#toc5.4">Developers information</A>
</H2>

<H3>64 bits numbers</H3>

<P>Many numbers are written in 64 bits, for example file sizes, in order to
avoid future limitations of the file formats. 64 bits variables must be declared as <B>QWORD</B>,
this is defined as <B>unsigned long long int</B> in <B>partimage.h</B></P>

<H3>reserved data for future use</H3>

<P>There is free space, reserved for future use, in the main header, and in each file header, in
order to add other informations in the future, without making archives files uncompatibles.</P>

<H3>variables names</H3>

<P>Variables names are written in the following format: <B>PositionTypeName</B>:</P>
<P>
<UL>
<LI><B>Position</B>: g_ for global variables, m_ for class members, and nothing for local variables.</LI>
<LI><B>Type</B>: b for bool, n for int, qw for QWORD, sz for a NULL terminated string in ASCII, c for a char, f for a FILE* stream, dw for DWORD, ...</LI>
<LI><B>Name</B>: the name of the variable, with an uppercase letter at the beginning of each word</LI>
</UL>
</P>
<P>Examples:</P>
<P>
<UL>
<LI><B>m_bArchiveOpened</B>: member of KFileCoderDoc (m_), of bool type (b), name = "ArchiveOpened"</LI>
<LI><B>dwLength</B>: local, of DWORD type (dw), name = "Length"</LI>
<LI><B>g_szArchivePath</B>: global variable (g_), null terminated ASCII string (sz), name = "ArchivePath"</LI>
</UL>
</P>
<P>This has a lot of advantages:
When you see a variable, you know the type (int, bool, FILE *), and you know if it's a global, local or member one.</P>
<P>Likewise, if two variables have the same name, if resolves the problem. For example, we have:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
bool CImage::m_qwCRC;

QWORD CImage::get_qwCRC()
{ 
  return m_qwCRC;
}

void CImage::setState(bool bState)
{
        m_bState = bState;
}
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>instead of:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
bool CImage::CRC;

void CImage::setState(bool state2)
{
        state = state2;
}
</PRE>
</CODE></BLOCKQUOTE>
</P>














<HR>
<A HREF="index-6.html">Next</A>
<A HREF="index-4.html">Previous</A>
<A HREF="index.html#toc5">Contents</A>
</BODY>
</HTML>
partimage-doc 20050720-3 / usr / share / doc / partimage-doc / html / index-5.html
