File recovery from complex folder structure using TestDisk

[spoolin01]

I hope I'm posting this to the right forum. I was advised by others, and the TD documentation I believe says the same, to conduct identifiable file recovery prior to partition recovery attempt.

I have a question about recovering name-identified files from a corrupted external backup drive that show as green after the simple TD analysis, in the context of lots of sub-foldering. I'm able to quickly retrieve any highlighted green files, but if a folder is among the items selected and copied for recovery to another disk, the process never seems to leave that folder, and while it seems to recover the right target files from inside that folder almost immediately, a process of failing to recover hundreds of thousands of files begins, and at least at 16 hours or so (for a folder that contained perhaps 30 files) the process hadn't yet moved on to other files that were seen in the green list, that were at the same directory level as the folder TD apparently started with.

Is there a solution to this that doesn't involve drilling down into every sub-folder cascade branch to highlight and recover the green files, with a separate process initiation at each node?

In order of importance, the kinds of files I want back are: PDF > xls/xlsx/doc/docx > exe/zip > iso > "installer" or other complex folders from microsoft and others, each with a variety of file types and sub-folders. Not much on the drive in the way of picture or video files.



The background, if useful:

1- Western Digital 4TB My Book external HDD used about 3 years as personal file backup drive became corrupted when a new USB 3.0 extension cable was inserted between the drive cable and a Win7 desktop PC. Drive still seen as USB device in system tray, but no file structure in Windows, and showed as uninitialized in Disk Management. I know it was the cable, because it also failed to work with a number of USB 3 thumb drives, and a 1TB portable drive, though it didn't corrupt any of those - they were either not visible to the PC, or recognized only as USB 2.0 devices. In the case of the 4TB My Book, the drive connected/disconnected rapidly for a few seconds before I pulled the plug. The next time I connected it properly, it was seen as uninitialized in Win7 Disk Management. Prior to this, Windows never put up any drive warnings, and both the WD disk utility and Hard Disk Sentinel currently show no SMART flags.

2 - I scanned (only, so I thought) the drive with the Easeus partition recovery software, after which in some instances, Easeus, Win Disk Management, or a couple of other drive utilities see the disk as MBR with two ~2TB unallocated partitions. So much for their process being non-invasive I guess.

3 - As best I recall, I used the WD disk as it came new, without any further partitioning, or change to the file system. In the process of refining my backup process, a fair number of files have been added, deleted, and moved among folders, to harmonize folder structure amongst the 3PCs and this drive, and to eliminate duplicates. I don't recall how much I filled the capacity, but I don't believe it exceeded 75%. I believe the disk was GPT with ex-FAT. TD sees files under the EFI GPT partition table option, and Bootice shows data first starting at Sector 2048 (with some minor data in Sector 0), and in a column labelled ASCII, I guess it translates the hexadecimal on the first line as ".v.EXFAT". Others have told me this means the drive was ex-FAT file system.

4 - Most or all of the files are mirrored elsewhere (this was a backup drive for personal files from 3 PCs with common foldering structure, and Free File Sync was used to mirror those to this drive, with versioning). So this instance is more a learning process for me. I do have another 2TB internal GPT drive - the predecessor to this one as my main backup drive - that I would one day soon like to try recovering files and/or partitions from.

5 - I don't know if this is related to all the file copy/delete and location re-arranging that has gone on, but in looking at what TD sees in any given folder, it looks like the first many lines of filenames are actually from the indicated sub-folder, but then lots of other green filenames show, which clearly were not currently located in that folder at the time the drive went south.

[recuperation]

Is it a portable 2,5'' drive?

[spoolin01]

Is it a portable 2,5'' drive?

For some reason I didn't get email notice of your reply. It's an external 3.5" drive.

[recuperation]

Is there a solution to this that doesn't involve drilling down into every sub-folder cascade branch to highlight and recover the green files, with a separate process initiation at each node?

No.