Delete/Remove corrupt NTFS file

Sorry I also tried to delete the folder the way you mentioned, as well as, 8.3 file deletion techniques and those techniques recommended for names including reserved names ie  >del \\?\c:\path_to_file\filename

They also fail with > File or folder corrupt.

Also, you can try 'slaving' that HDD off another computer and attempt to delete it that way.

This is fun stuff - I haven't answered a question in so long, I've about forgotten how.

I would also suggest that this be added to the 'Security' Zone - lots of Geniuses (Genii) up there who are really solid on file manipulation.

V

Thanks V. Nice to see you as well. I will look into the BFU link you mentioned. As for slaving I made an image of the disk and slaved it on my WS. That's the disk I'm working with so I don't interfere with the user.

Your issue; though, is illegal filenames and, on anything but NTFS, we could have easilly used ye old DiskEdit to erase the file.  If you guys know of a similar utility that would work on NTFS, I'd love to hear about it.

Not sure if we're talking about the same 'slaving' process.

I'm thinking of taking the actual (physical) HDD from that computer and slave it off of yours. (Tell the other guy to take the rest of the day off.)

If it is physically slaved, none of the files should have the various 'hooks' that Windows puts on files - and you should have greater access/control.

Vic

Two more thoughts.
Re-boot into "Safe Mode" and try deleting then (fewer OS Processes) and
If you have a "USB Enclosure", try attaching the physical HDD to the enclosure, then access it through your USB connection.

I've been using my USB Enclosures a lot lately to recapture all manner of 'deleted/missing' files.

Your computer will treat the entire HDD as a giant "Flash Drive" - basically treating it like a FAT/FAT32 partition (no NTFS properties).

Vic

First thanks for the suggestions offered thus far.

Vic,
      I think were on the same page. I am using an External USB adaptor to access the HDD. Also, this is in fact, the original HDD that was in the users machine. I originally thought it my be a HDD error so I did a raw disk copy and installed the duplicate in the computer.
      As for your statement & - basically treating it like a FAT/FAT32 partition (no NTFS properties). Im not sure thats the case. If a disk is formatted with NTFS, as far as I know, it can only be accessed from an NTFS aware OS or utility bringing me back to the problem of the ACL being non-existent thus preventing any alteration to the file. This is also a problem while in Safe Mode for the same reason. I also know it is not an access problem with regard to any using processes. Thats why I feel a HEX utility editing raw data is likely the only way bypass the problem. Problem with that route is I know very little about using this type of utility.

DavisMcCarn,
      I still dont the file name is the root of the problem; though it is possible. I think a HEX Editor (or Disk Edit utility) would probably be able to relieve this problem I just have very limited knowledge in using this type of utility. I would need information about where to locate the MFT,  what sector to edit, what information I would be looking for, etc& If I have time to figure this out I may do that.
I think this would work because I should be able to delete the pointer to the file in the MFT which should prevent it from showing up in Explorer causing the OS to consider the area where the file was written on the disk to be free space allowing it to be written over. As you likely know, this is the process the OS performs when a file is deleted through normal means.

You've got me thinking about the File System stuff. I am so used to 100% NTFS on XP boxes, that I forget civilians can do anything they want.

About half the time that I plug in a HDD with the USB Enclosure, I get the pop-up about fixing the FAT/FAT32 File Structure. Which probably only means that it is not formatted NTFS - still learning.

I'm holding out hope for BFU (love that name) and will monitor for other suggestions.

Thanks,
Vic

I'll probably get to try that tomorrow so I'll let you know.

FYI BFU also did not work.

Krompton,
I have been using Norton's Diskedit since 1984 or 5; but, the function I havent been able to find in an NTFS utility is the ability to drill through the directory tree using the mouse (or keyboard) to get to the messed up folder.  As an example, I must have seen 50 systems hit by a bug in Windows 95 that trashed a random sector in the Windows\System folder, instantly renderring them non-bootable, and the fix was to use Norton to manually re-enter "Dummy1, Dummy2, (etc) as filenames to allow access to the rest of the folder.  Only once, was a critical file needed to boot in the trashed sector and that was easilly copied from a working system.
The server I mentioned wouldn't be so tedious if I could do that on NTFS.

Meanwhile; though, back at the ranch, you may not have an illegal filename as the culprit (but you could) and there is definitely something wrong with the entry if it has no ACL.  If you did delete the entry with a hex editor, I'll bet chkdsk would fix the MFT.

DavisMcCarn,

You are correct on both the diskedit of 9x and NTFS. Also the filename could be a problem and in fact I believe it is in a way. Not that it is the actual name but (You probably already know this though) that the MFT entries for NTFS are case sensitive but the Explorer interface is not. Open search and look for XZY.exe and it will find xyz.exe. Try to name a file XYZ.exe and xyz.exe in the same folder and it will flag that the name already exists. But if XYZ.exe is for some reason listed in the MFT as xyz.exe then the filesys has a problem because as it tries to apply the ACL to xyz.exe it cannot locate that file because it sees XYZ.exe starting there instead. This is why no security tab appears because one was never applied to that file. Drawback to this is that chkdsk does not look for lettercase mismatches. It work the same way as the explorer interface does. xyz.exe znd XYZ.exe are the same as far as it is concerned and therefore makes no changes. That's why I think it likely that a hex utility is porbably the only way to get around this. But I was hoping someone here may have found another way or had decent directions as to how to accomplish this with the editor.

Thank you for your input even if it isn't what I was hoping for.

Cheers

Even though I did not get the answer I had hoped for I thank you for your inputs.

Thanks. I am glad the question is saved because the various suggestions may prove helpful in similar future cases.