Unable to recover files deleted with XP "rd /s /q" command

[smfabac]

I have tried to use Recuva v1.42.544 on an external USB hard drive where my backup software creates its backup archives. The backup script tests the remaining free space on the disk to see if it is more then the specified free space available. If not, it deletes old archive folders until enough free space is available to meet the specified amount.

 

The problem that bit me is that I had a USB hard drive with old archives, that I wanted to keep, connected to my system by mistake. The backup script did its work and dutifully deleted the old archives. luckily (I thought), there still was not enough free space to perform the nightly backup and so the backup program exited without writing new data to the disk.

 

Well Recuva finds the deleted folder but the archive file header is shown as zero size and can't be recovered. This is a 19G file (before the script deleted it).

 

Checking the script I see that the command used to delete the archive folder (named as 20110612, and a subdirectory of E:\IFW_images) is: rd /s /q "%DeleteDir%" The script deleted subdirectory 20110612 and it's parent directory E:\IFW_images as well (probably a bug in the script to delete the empty parent directory).

 

I have had no luck googling for an undelete program that can recover from this error (using rd /s /q folder_name). No one seems to be aware of the issue. I have given up trying to find an undelete that will work in this instance and for the future will look for a replacement utility for "rd" that will work with Recuva.

 

Do you have any suggestions?

[Augeas]

This issue is, as far as I determine, due to the way NTFS handles deletion of large files (in excess of 4gb). It is not specific to the way the file was deleted or to Recuva.

 

As your file was 19 gb the file system must be NTFS. When the file was allocated a 1k record was created in the Master File Table: fields in this record point to one or more data runs (cluster lists) which hold the file data. Normally when a file is deleted NTFS updates some of the fields in the MFT record to show that the file has been deleted. The cluster information in the data runs isn't updated so Recuva is able to locate the file data and recover it successfully.

 

However NTFS acts differently when the file size exceeds 4 gb. The fields holding the file sizes are set to zero, and the data runs (the critical information for locating the file data) are truncated and overwritten with an EOF marker. The file now shows as zero length. As the information for locating the file data has been lost the file is not recoverable by Recuva running a normal scan, or any recovery software looking at the MFT.

 

In both cases the file data is untouched. Although the data may still be on the disk, the only way to find it is to look at every cluster and try to identify the starting cluster of the file by looking for a file signature. If the file signature is recognised by Recuva (and I don't know what the backup software uses), and the file is in one extent (doubtful for such a large file?) then the file might be recoverable, even if the name is lost. I should advise running a deep scan, and then - in Advanced Mode - sort on file size. If you find a 19 gb file of the approximate date then you might be in luck, in very, very deep luck. If the file is in several extents then Recuva will not be able to find anything except the first extent, so file recovery will fail.

 

Data recovery shops could quite possibly extract all the clusters from the disk and piece together your file, but that won't be free.

 

This 4 gb issue is known, but the reason why isn't, except by those who wrote NTFS. I doubt whether the ability to recover deleted files was included in the spec for NTFS.

[Alan_B]

The "backup software" REALLY should have been clearly identified.

 

Due to inadequate information an alternative interpretation might be that the 19 GB was not a FILE but an ARCHIVE.

 

\IFW_images Suggests a partition/disc image backup.

Such software may typically delete old stuff to make way for a new archive,

and typically has the ability to create a 19 GB archive on FAT32 as a series of 4 GB files.

 

A quick search on the Internet for \IFW_images suggests Rollback or Terabyte as possible creators :-

http://www.terabyteu...for-windows.htm

http://horizondatasy...ted-disk-7.html