corrupted file just won't die

@Phillip,

Subject to the results of testing for bad sectors, and since I'm out of good, detailed, new ideas myself, I found a laundry-list of things Microsoft suggests trying when "you cannot delete a file or folder on an NTFS file system volume" - aka KB Article 320081.

The KB article lists the following (potentially relevant) causes:

• Cause 1: The file uses a non-canonical ACL
  MS suggests using a security permission editor such as Cacls.exe to reset the security permissions so that you, as admin, have ownership and full control.
  .
• Cause 2: The file is being used
  Doesn't sound likely, but MS suggests using Sysinternals' Process Explorer to determine what process is using the file; presumably you would then kill that process and delete the file.
  .
• Cause 3: File system corruption is preventing access to the file
  MS suggests using Chkdsk.exe, which you've already done to no apparent effect.
  .
• Cause 4: Files exist in paths that are deeper than MAX_PATH characters
  This one might be pertinent, although I cannot recall if you ever stated how long the file path was. MS suggests the following remedies:
  .
  • Resolution 1: Use an auto-generated 8.3 name to access the file
    Basically, try to reference the corrupt files using the old MS-DOS 8.3 name protocol; for backwards compatibility, the NTFS system also generates alternate names using the 8.3 format. For example, the file IHaveABigName.exe could be referred to as IHaveA~1.exe, or IHave~12.exe in the old 8.3 name format. In this case, you could simply guess at the 8.3 name, which should generally be in the format abcdef~1.xyz if there aren't any other files with the same first six letters (case-insensitive) in their long file names.
    .
  • Resolution 2: Rename or move a deep folder
    This also takes into account using the old 8.3 name format. Basically, many apps apparently assume that the total length of the absolute file-path\file-name URI is less than 255 characters; if it's longer, then you may not be able to delete the file because the system cannot "get" to it. MS suggests either renaming intervening folders in the path-name with shorter names to get the total path\file character count under 255, or else moving one of the folders that contains the corrupt file up to root so that the path\file length is less than 255. For example, if the full path was c:\...250-chars...\LastFolder\CorruptFile.BAD, moving folder "LastFolder" up to root at c: would give a URI of c:\LastFolder\CorruptFile.BAD, which is, obviously, less than 255 characters.
    .
  • Resolution 3: Map a drive to a folder in the structure of the path
    This is another way to deal with too-long file-paths. Basically, what you do is go into the disk manager and map a logical drive letter to one of the folders in the file-path that occurs just before the corrupt file. So, for example, if you started out with c:\...250-chars...\LastFolder\CorruptFile.BAD and then mapped drive letter z: to LastFolder, you would get a new logical drive that contained z:\LastFolder\CorruptFile.BAD, which, again, has a path length of less than 255 characters. This could also be useful if the file-path itself were corrupt (e.g., an illegal character in a path-name, or the use of a reserved name that is undeletable).
    .
  • Resolution 4: Use a network share that is as deep as the folder
    Similar to Resolution 3. MS suggests as follows: "If Resolution 1, 2, and 3 are not convenient or do not resolve the issue, create a network share that is as deep in the folder tree as you can, and then rename the folders by accessing the share."
    .
  • Resolution 5: Use a tool that can traverse deep paths
    MS doesn't have anything particularly useful to suggest here.
  .
• Cause 5: The file name includes a reserved name in the Win32 name space
  Certain names are reserved under Win32 and, if used in a file-path, cannot be deleted. Basically, MS suggests using a non-Win32-based tool, such as a POSIX-based tool, to attempt to delete the file (no utilities are referenced ). MS also suggests that you may be able to use a Win built-in command by using a different naming syntax. MS gives the example of "del \\?\c:\path_to_file\lpt1" which is a commandline command to delete the file "lpt1" (which is a reserved name, so using it as a file name is illegal). this last suggested solution is spelled out in more detail in KB Article 315226.
  .
• Cause 6: The file name includes an invalid name in the Win32 name space
  This cause covers instances where one of the names in the file path, or the file name itself, contains non-permitted characters, such as a trailing "." or trailing empty space " ". Those trailing characters are stripped off when the normal file-path-name is used, with the result that a file with the name "AFile.txt " will be treated as "AFile.txt" and the former file therefore becomes inaccessible using the normal file path reference. MS also mentions this occurring if the file's name is just an empty space - " " - in which case it exists, but Windows cannot reference it. So, for example, if the full path name was c:\Folder1\ \Folder2\CorruptFile.BAD, you would not be able to reference CorruptFile.BAD using that path-name, because the empty space would be stripped away, leaving the full path reference as c:\Folder1\Folder2\CorruptFile.BAD, which doesn't exist.
  .
• Combinations of causes
  Last but not least, there's any combination of the foregoing problems.

.
I don't know if you've already tried all of these methods or not, but if not, perhaps either one will work, or will give you some more insight into what the issue is.