I've done that before when drives get back to the office for space saving and backup, but for some reason it's not zeroing out anything, it's just either giving an error that it can't continue, or it gives the 198 Days 12 hours type of a countdown.
Have you tried maxing the error granularity and block size in EnCase acquisition mode to 'help' it skip over the problem?
Athulin. The 200 files I'm speaking of are .e01 files …
In that case, extend my suggestion cover those, too, in a chkdsk verification.
Quick summary to see if we have it straight.
Doing a copy of offending 2GB file using file system hangs the copy process (on NTFS I assume).
The image mounts, but doing a copy from files in the image also causes a similar problem. The copy process never finishes.
So how about trying to avoid the file system. Get a disk hex viewer and copy out the disk sectors associated with the file. If you are lucky the file will be unfragmented and a single carve can get the file. Another wise you might need to carve each fragment and then stick the file back together.
If this still fails then at least you know that that it isn't the file system that is the problem, it is the physical drive. You might be able to narrow the problem down to a single sector by doing this.
What you might find however is that the hex viewer has a problem figuring out what clusters are associated with the file in the file system. If this is the case, then the problem is with the file system, and the drive itself might be OK. Stepping through the NTFS structures might then allow you to fix up the file system, but it might be tedious. (Chkdsk might help in this case).
Another simple test to narrow the problem down would be to make an dd image of the physical disk that holds the 200 files. So you'll have a dd image which contains an .e01 image. If this works, then it is the file system at fault. It also means you can then started editing the MFT of your dd image until you can get back the .e01 file.