Mac HFS File System for Apple Data Recovery

Data Recovery for HFS : File System for Macintosh

Hierarchical File System (HFS), is a file system developed by Apple Computer for use on computers running Mac OS. Originally designed for use on floppy and hard disks. HFS is also referred to as Mac OS Standard to differentiate it from its successor HFS Plus which is called Mac OS Extended.

Hierarchical File System is used by the users of Mac OS. It is also known as Mac OS standard to keep it separate from HFS plus. HFS plus is called Mac OS Extended.

In HFS, files are grouped into directories (also called folders), which themselves are grouped into other directories.

Disk Space Management

HFS divides the total space on a volume into equal-sized pieces called allocation blocks. It uses 16-bit fields to identify a particular allocation block, so there must be less than 216 (65,536) allocation blocks on an HFS volume. The size of an allocation block is typically the smallest multiple of 512 such that there are less than 65,536 allocation blocks on the volume (i.e., the volume size divided by 65,535, rounded up to a multiple of 512). Any non-empty fork must occupy an integral number of allocation blocks. This means that the amount of space occupied by a fork is rounded up to a multiple of the allocation block size. As volumes get larger in size, the amount of allocated but unused space increases.

Features

  • A hierarchical directory structure:
  • Directory support
  • UNIX–style permissions support for security
  • Local sockets support
  • Extended attributes support
  • Data conversion support
  • Absolute and relative pathnames
  • Hard links and symbolic links
  • Stream files
  • Save and restore support

Volume Design

The Hierarchical File System divides a volume into logical blocks of 512 bytes. These logical blocks are then grouped together into allocation blocks which can contain one or more logical blocks depending on the total size of the volume. HFS uses a 16 bit value to address allocation blocks, limiting the number of allocation blocks to 65,536.

There are five structures that make up an HFS volume:

  • Logical blocks 0 and 1 of the volume are the Boot Blocks, which contain system startup information. For example, the names of the System and files which are loaded at startup.
  • Logical block 2 contains the Master Directory Block (aka MDB). This defines a wide variety of data recovery information about the volume itself, for example date & time stamps for when the volume was created, the location of the other volume structures such as the Volume Bitmap or the size of logical structures such as allocation blocks. There is also a duplicate of the MDB called the Alternate Master Directory Block (aka Alternate MDB) located at the opposite end of the volume in the second to last logical block. This is intended mainly for use by disk utilities and is only updated when either the Catalog File or Extents Overflow File grow in size.
  • Logical block 3 is the starting block of the Volume Bitmap, which keeps track of which allocation blocks are in use and which are free. Each allocation block on the volume is represented by a bit in the map: if the bit is set then the block is in use; if it is clear then the block is free to be used. Since the Volume Bitmap must have a bit to represent each allocation block, its size is determined by the size of the volume itself.
  • The Extent Overflow File is a B*-tree that contains extra extents that record which allocation blocks are allocated to which files, once the initial three extents in the Catalog File are used up. Later versions also added the ability for the Extent Overflow File to store extents that record bad blocks, to prevent a machine from trying to write to them.
  • The Catalog File is another B*-tree that contains records for all the files and directories stored in the volume. It stores four types of records. Each file consists of a File Thread Record and a File Record while each directory consists of a Directory Thread Record and a Directory Record. Files and directories in the Catalog File are located by their unique Catalog Node ID (or CNID).
  • A File Thread Record stores just the name of the file and the CNID of its parent directory.
  • A File Record stores a variety of metadata about the file including its CNID, the size of the file, three timestamps (when the file was created, last modified, last backed up), the first file extents of the data and resource forks and pointers to the file's first data and resource extent records in the Extent Overflow File. The File Record also stores two 16 byte fields that are used by the Finder to store attributes about the file including things like its creator code, type code, the window the file should appear in and its location within the window.
  • A Directory Thread Record stores just the name of the directory and the CNID of its parent directory.
  • A Directory Record stores data like the number of files stored within the directory, the CNID of the directory, three timestamps (when the directory was created, last modified, last backed up). Like the File Record, the Directory Record also stores two 16 byte fields for use by the Finder. These store things like the width & height and x & y co-ordinates for the window used to display the contents of the directory, the display mode (icon view, list view, etc) of the window and the position of the window's scroll bar.

Power Failures

Due to power failure, data can be lost which is not buffered, but the file system structures, directories, inodes and such, will not be damaged. The HFS does its own repair, as needed, on each mount of a file system. This is based on records it keeps of changes in progress. But there is always a possibility of data recovery, critical file system data, or the media can be damaged, so prudent backup procedures are always warranted. This is true for even for file systems that have an fsck utility, which generally ensures structural integrity, not data integrity. In case of damaged media like damaged hard disk drive, tape and damaged raid server, contact our expert data recovery professional at Optimum Data Recovery, Inc.

Data Recovery info image For data recovery, visit www.optimumrecovery.com

Top of current page info Up

 

About Us  |   Data Recovery Services   |  Data Security  |  Privacy Policy  |   Partners  |  Testimonials  |  Contact Us  |  Site Map
Data Recovery UK | Data Recovery US
Copyright 2006 © Optimum Data Recovery, Inc.