[clue] NTFS logical structure corruption?

[dshaw at famece.com]

Hi all-- so I got to spend some time with this troublesome machine again
last night with some interesting (I think) results. Working from
yesterday's e-mails, but changing the order a bit, I wrote:

> I have another laptop with XP and a copy of Fedora
> loaded on it that I should be able to get running
> tonight. I'll see whether that produces any interesting
> comparisons.

So this was Fedora 15 sharing a laptop with XP. Booting Fedora and
mounting the NTFS partition revealed the same symptoms I saw in Ubuntu,
i.e., seemingly random files showing 2 hard links that couldn't be
confirmed by searching for those inode numbers. I'm thinking the current
Linux kernel, or whatever NTFS support they use, isn't reliably picking up
this bit of data. Otherwise both Fedora and Ubuntu seem to be able to
navigate, access, and alter the NTFS system ok. So I'm calling this a red
herring and moving on.

Regarding the various suggestions for file ownership/permissions:
>> Can you find a version of WINFILE.EXE (the
>> 1) Use CHKDSK to repair the filesystem
>> 2) Use TAKEOWN to take ownership of the
>> 3) Use ICACLS to give Administrators:Full

Several of these seem to be available only from Vista on, so I didn't try
to pursue. On XP, "attrib" and "cacls" seem to be the tools of choice. I
*have* successfully run chkdsk many times, with no errors shown. Dipping
almost to the bottom of my XP knowledge, I booted the machine into safe
mode, logged in as administrator, and tried to look at the permission
stuff. The folder just above the problem folder correctly shows a
"Security" tab, with associated permissions, etc. Trying this same thing
on the errant folder shows *no* security tab, so I couldn't look at who
owns it, permissions, etc., and attrib and cacls wouldn't operate on the
file. Which brings me to:

>> If you boot the machine from a Windows XP
>> CD and enter the recovery console, can you
>> delete the file?

No, because I can't cd into (or otherwise search) that directory. However,
I *could* see more info on that directory using "dir" from the recovery
system in the folder just above. It showed me the permissions on the
problem folder were: d----c-p. I tried to make some sense of what that was
trying to tell me, but other than the "c" meaning it was a "compressed"
directory, I didn't get far. I did turn on "readability" with cacls, and
opened up ownership a lot with attrib, but that didn't help, and it was
getting late, so I quit.

As an aside, after adding readability, running "dir" from the XP on the
machine (not the recovery console) said the directory was a <junction>,
whatever that is, instead of it being a <dir>. Something to do with shared
files?

So now I'm thinking the whole thing is just a munged permissions problem,
with this condition shutting down various aspects of normal programmatic
access to the folder, including Linux ability to access the directory (I
believe this is separate from the multiple hard link problem).

Rather than continue to waste everyone's time on a Windows problem, I
think I may have a solution that doesn't involve me becoming an expert on
NTFS permissions and how to fix them. The Maxblast software I have
available doesn't have a "restore everything but" option, but it does have
a "restore specific folder" option, supposedly at a new location. I'm
going to try setting up and archiving a fake (clean) folder of the same
name as my offending folder, and try restoring that on top of the bad one
on disk. Worth a shot. Unless anyone has a better plan.

Thanks for all the help on this one.

Dave Shaw