TODO

* superblock offset and number can be both used to guess if the block number
  at which it appears is correct and in the case if 2 superblocks are in the
  same part, the distance between both can tell a lot of things :) 

* raw remaining data (in undetermine/unknown state) can be dumped as well to be
  analysed by a external tool or manually.

* use the errno == EINTR when a read process can be interrupted by a signal (for
  the progress display).

* when analysing dir content block, if a block isn't recognized as a block dir content
  we can dump it to a file a make it anaylsed by the 'file' command, if it return
  something different than 'data', then we can move it to '1stblock' directory
  This block must be available as NOTFREE or UNKNOWN and not DUMPABLE.

* when a directory stub is added, if its parent directory has a inode == 0
  then we can admit that the actual parent_inode in the stub can be affected
  to the parent inode number.
  Then, we can have multiple stubs with the same inode number that we must merge.

* when we affect an inode number to a directory (a portion of a directory) that
  do not know its inode number, it could happen that for the same directory we've found
  multiple inode number. A solution must be found to solve this problem.

* when directory blocks have been identified, try to determine which blocks can be
  concatenated.

* some blocks are marked in the block bitmap data as used but doesn't seems
  to correspond to something. So they are analysed by the scan_for_directory_block.

* in mark_data_blocks don't forget to collect data blocks of directories
  from which we have the inode but not the first block containing the stub.

* if part is a block device, logi_offset is equal to phys_offset or
  must be adjusted taking into account phys_offset value. 

* make more use of the LOG function :)

* generally, structures are fully loaded, but it can happen that
  only a part of the structure is available. But it might be possible
  reassemble every portion available to recreate the whole structure.
  In the case of the superblock, only few field are interesting for us
  so when we are sure to have all these fields every thing is fine (more
  or less).

* Truncated structures aren't analysed/considered, but not all the field of the structure
  intersted us, so they can be loaded. Typically, group description table can be loaded
  piece by piece if no one can be fully loaded.

* when scanning for superblock, we can consider all different type of dates (last mount,
  creation date, last check, ...) instead of just using one reference date.

* make some errors do not appear more than one time (example block device file
  creation can't be done if you're not superuser).