• iRecover uses the conventional Windows API to open a file, this is done in the same manner as all Windows applications (like Notepad) open files.
• The source disk is read in blocks. If there's no physical damage and the disk was scanned without problems, there should be no problem here. Reading the disk directly is done using a Windows API which allows an entire drive or disk to be opened and treated as a file. iRecover only moves a pointer through this file to read the correct blocks of data.
• After reading a block of data, iRecover calls a Windows API and requests the block to be written to the file that was opened in the first step.
• When all blocks are processed iRecover calls a Windows API to close the file. The file is now copied and iRecover can move on to the next file (if any).
  99 % of slow-downs during file copying are because iRecover is waiting for a Windows API call to respond.
• If iRecover is trying to read a block of data from the source disk, it can only continue after the Windows API has completed the request. If reading the source disk is the bottleneck, this may indicate that the source disk is going bad. Clone the source disk as soon as possible.
• If iRecover writes to a file it may be waiting for the API because the destination is slow. This may be the case when you are writing files to a network location or other relatively slow media, or maybe the destination disk isn't configured properly.
• In general when the destination drive is slow, normal file copying to this same drive is slow as well. So a slow (target) drive will make iRecover file copying slow too.
• All software that interferes with reading/writing files (for instance on-access virus scanners) will make the recovery process slower, you should disable these processes.

General hint: make sure the operating system supports the disk sizes of both the source disk AND the destination disk. We see a lot of problems in this area. Older operating systems can not cope with disks > 137 Gb. The newer ones like Windows XP only can after the appropriate service pack is applied. Always make sure the system BIOS can cope with disks > 137 Gb no matter what OS. Find more information on this subject here.

The root is the folder under which (in normal circumstances) all your files are stored. The root branches into sub-folders. iRecover shows this in a similar way: if there's a 'Root' in the list, expand it to view files/folders in the same order as you'd expect to find them under normal circumstances. Normally iRecover will identify the root correctly when dealing with recovery from deleted partitions, recovering deleted files or any other damage that did not 'trash' the root folder.

Note: When dealing with a reformatted drive the root (if present) is empty. This is caused by the fact that re-formatting a drive 're-initializes' the root folder.

• The disk is bad, meaning a lot of sectors can not be read:
  Consider the disk may be 'dying'. If you'd continue the recovery attempt with iRecover (or any other file recovery utility), multiple additional reads are required before you have actually recovered a file. If a disk is really dying, each good read could be the last. You should clone the disk before performing further file recovery! Cloning the disk will read the entire disk in one pass. File recovery software can be run on the clone without further endangering the condition of the problem disk and it's data.
• Lack of OS support for large disks:
  To access a drive, iRecover uses the Windows API. If Windows does not fully support large disks, neither does iRecover. Problems with accessing disks larger than 128Gb are common. These problems can be attributed to BIOS problems and incomplete OS support for large disks. Read more here.

The following is a brief description of the requirements for 48 bit LBA support:

Windows XP supports 48-bit LBA with Service Pack 1. You must also have a 48-bit LBA compatible BIOS.

Windows 2000 supports 48-bit LBA with Service Pack 4. You must also have a 48-bit LBA compatible BIOS. To enable 48-bit LBA support with Windows 2000 SP4 you must edit the Windows registry.
To enable 'EnableBigLba' in the Windows registry, perform the following steps:

1. Start a registry editor (regedit.exe). In Windows, click on Start->Run, enter "regedit"
2. Navigate to the
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters
   registry subkey
3. From the Edit menu, select New, DWORD Value
4. Enter the name EnableBigLba, then press Enter
5. Double-click the new value, set it to 1, then click OK
6. Close the registry editor

Restart the machine for the change to take effect.