disc problem 2: chkdsk deleting orphan files

[Stephen]

Hello again,

When I boot wondows xp, chkdsk appears and tells me that one of my
discs needs scanning. Unfortantely, I left my machibne to boot
unattended and when I walked into the room I found it with a screen
full of messages that it was deleteing orphan file record xxxxx.

I had a panic that it was deleting perfectly good files, so I switched
the computer off before it could do any more.

Now when I boot, I press any key to skip the scan but Windows will not
allow me to view the disc, saying that it is "not accessible: the file
or directory is corrupted and unreadable".

I did delete some dvds that I had copied to the disc, so it could be
that these orphan files are the dvd files that were not deleted
properly but on the otehr hand, I worry they could be genuine files
that I want to keep.

What is the best thing to do? Is there siome softywarre that could
read the disc and copy the good files across? Or should I allow chkdsk
to delete the orphan file records and see what is left?

If it is only deleting file records, does this meant he actual files
will be recoverable by some other means?

Thanks again,
Stephen.

[Jaimie Vandenbergh]

On Tue, 03 Sep 2013 21:50:09 +0100, Stephen
<ste...@nowhere.com.invalid> wrote:

>Hello again,
>
>When I boot wondows xp, chkdsk appears and tells me that one of my
>discs needs scanning. Unfortantely, I left my machibne to boot
>unattended and when I walked into the room I found it with a screen
>full of messages that it was deleteing orphan file record xxxxx.
>
>I had a panic that it was deleting perfectly good files, so I switched
>the computer off before it could do any more.

That was a mistake, unfortunately. CHKDSK generally does the best that
can be done with the existing data, it will vanishingly rarely cause
*more* issues.

From MS:
"An orphaned file is one for which a legitimate FRS (file record
segment) exists, but which is not listed in any directory. When an
orphaned file is found, it can often be restored to its rightful
directory, provided that directory is still around. If the directory
that should hold the file no longer exists, CHKDSK will create a
directory in the root directory and place the file there. If directory
listings are found that reference FRSs that are no longer in use or
that are in use but do not correspond to the file listed in the
directory, the directory entry is simply removed."

If you'd left it, those orphaned files would have been put into a
"Rescued Files" folder in the base of the drive. It was the 'records'
that were being deleted, not the files themselves.

>Now when I boot, I press any key to skip the scan but Windows will not
>allow me to view the disc, saying that it is "not accessible: the file
>or directory is corrupted and unreadable".

That would be due to you pulling the power while CHKDSK was messing
with the low-level records on the disk, I'm afraid.

>I did delete some dvds that I had copied to the disc, so it could be
>that these orphan files are the dvd files that were not deleted
>properly but on the otehr hand, I worry they could be genuine files
>that I want to keep.
>
>What is the best thing to do? Is there siome softywarre that could
>read the disc and copy the good files across? Or should I allow chkdsk
>to delete the orphan file records and see what is left?

Allow CHKDSK to complete.

If you really want to be safe, take a clone of the hard drive
partition before doing that - any partition management tool will do
this for you.

Again, sort out your backups. Once you have backups, a disk eating
itself is reduced to a minor time waster, little more.

Cheers - Jaimie
--
"Hard as nails, hard as nails - So would you be if you lived one hundred
and eighty years on sunflower seeds and biscuit crumbs." - Polynesia

[Mike Tomlinson]

En el art�culo <4fic299fn9tc03m4j...@4ax.com>, Stephen
<ste...@nowhere.com.invalid> escribi�:

>When I boot wondows xp, chkdsk appears and tells me that one of my
>discs needs scanning.

FAT32 or NTFS?

> Unfortantely, I left my machibne to boot
>unattended and when I walked into the room I found it with a screen
>full of messages that it was deleteing orphan file record xxxxx.
>
>I had a panic that it was deleting perfectly good files, so I switched
>the computer off before it could do any more.

That was a rather silly thing to do wasn't it, given that chkdsk would
have been very busy working with the file allocation table (FAT32) or
master file table (NTFS). You've yanked the power while it's been
writing the table to disk, so now you have a non-existent or
partial/corrupt file table.

NTFS is more robust in this regard, hence my first question. If the
filesystem is NTFS, your chances of recovery are good.

>Now when I boot, I press any key to skip the scan but Windows will not
>allow me to view the disc, saying that it is "not accessible: the file
>or directory is corrupted and unreadable".

Little surprise.

>I did delete some dvds that I had copied to the disc, so it could be
>that these orphan files are the dvd files that were not deleted
>properly

unlikely

>What is the best thing to do? Is there siome softywarre that could
>read the disc and copy the good files across?

TestDisk, www.cgsecurity.org. Run it, let it search for the partition
table. It might say it's corrupt and offer to look for the spare copy
and write that to disk. Accept. Then either use TestDisk to copy off
individual files/directories, or try reading the disk from Windows
again. Be grateful if you are able to get any data at all back.

> Or should I allow chkdsk
>to delete the orphan file records

Well, they will be inaccessible by Windows anyway so you may as well let
chkdsk delete them to free up the space. But run TestDisk first

>If it is only deleting file records, does this meant he actual files
>will be recoverable by some other means?

In theory, yes.

You'll backup next time, won't you :-)

--
(\_/)
(='.'=)
(")_(")

[Gordon]

On 2013-09-03, Jaimie Vandenbergh <jai...@sometimes.sessile.org> wrote:
> On Tue, 03 Sep 2013 21:50:09 +0100, Stephen
><ste...@nowhere.com.invalid> wrote:
> If you really want to be safe, take a clone of the hard drive
> partition before doing that - any partition management tool will do
> this for you.

Read, how much is your data worth? A clone is merely a back up. Play with
the clone and when needed do some mor cloning to get as many copies as one
needs.

>
> Again, sort out your backups.

As in do them. at regular intervals. most of them will be deleteable, but
the odd one or two will be invaluable.

> Once you have backups, a disk eating
> itself is reduced to a minor time waster, little more.
>

Totally wrong. One is suddenly totally aware, relieved that one created
a backup and the time spent doing it suddenly seems so worthwhile. ;-)

There is nothing that rises faster in value as a backup when it is needed.

No one has ever complained of having too many backups. Yes, your might
require three at some point in your life time to get your data back.

[Stephen]

On Tue, 03 Sep 2013 22:21:02 +0100, Jaimie Vandenbergh
<jai...@sometimes.sessile.org> wrote:

>
>That was a mistake, unfortunately. CHKDSK generally does the best that
>can be done with the existing data, it will vanishingly rarely cause
>*more* issues.

As I said, I went into a panic at the time.

>
>From MS:
>"An orphaned file is one for which a legitimate FRS (file record
>segment) exists, but which is not listed in any directory. When an
>orphaned file is found, it can often be restored to its rightful
>directory, provided that directory is still around. If the directory
>that should hold the file no longer exists, CHKDSK will create a
>directory in the root directory and place the file there. If directory
>listings are found that reference FRSs that are no longer in use or
>that are in use but do not correspond to the file listed in the
>directory, the directory entry is simply removed."
>
>If you'd left it, those orphaned files would have been put into a
>"Rescued Files" folder in the base of the drive. It was the 'records'
>that were being deleted, not the files themselves.

At the time I had no idea what the message meant and I guessed it the
wrong way round, thinking it was deleting files that had no
directory. That's why I wrongly thought in my OP that it might be
deleted files that had not been deleted properly. The problem is that
whilst check disk is running you can't google to see what the message
means ;)

>That would be due to you pulling the power while CHKDSK was messing
>with the low-level records on the disk, I'm afraid.
>

>Allow CHKDSK to complete.
>
>If you really want to be safe, take a clone of the hard drive
>partition before doing that - any partition management tool will do
>this for you.

I downloaded acronis trueimage and imaged the disc before running
chkdsk. Acronis could read the disc even though windows could not. I
imaged the drive which took 24 hours.

Then I ran chkdsk. I thought I had lost a lot of files because I had a
lot of empty folders or folders with one or two files in but I think
what has happened is that these were deleted folders that have been
restored by chkdsk. I found the same folders with all their files on
my other disc, I think the folders were originally on the disc A and I
copied them to disc B and chkdsk has found remnants on disc A and
restored them, if that makes any sense, I know my explanation is not
brilliant.

Anyway that disc seems to be back to normal now. I used to use
Norton's disc doctor. Is that still around/recommended? I thought it
used to be better than scandisk and chkdsk.

Now to fix that other disc...

Thanks,
Stephen.

[Jaimie Vandenbergh]

On Fri, 13 Sep 2013 07:59:56 +0100, Stephen
<ste...@nowhere.com.invalid> wrote:

>Then I ran chkdsk. I thought I had lost a lot of files because I had a
>lot of empty folders or folders with one or two files in but I think
>what has happened is that these were deleted folders that have been
>restored by chkdsk. I found the same folders with all their files on
>my other disc, I think the folders were originally on the disc A and I
>copied them to disc B and chkdsk has found remnants on disc A and
>restored them, if that makes any sense, I know my explanation is not
>brilliant.

That's exactly right - and a good example of chkdsk erring on the side
of "It's not certain these were deleted rather than accidentally lost,
so I'll resurrect them just in case". Glad it all came back together.

Cheers - Jaimie
--
I like my coffee how I like my women... frothing.

[Johny B Good]

On Fri, 13 Sep 2013 07:59:56 +0100, Stephen
<ste...@nowhere.com.invalid> wrote:

That seems an awfully long time to clone a disk but this is a piece
of string for which we have no data to usefully speculate upon.

Assuming a USB2 connection, a 1TB disk could take a good 8 or 9 hours
to clone, assuming the source disk isn't failing and plagued with bad
sectors. If the new disk is connected via a SATA port (assuming a SATA
connected source disk) it would take only around 3 to 4 hours.

24 hours would be about right in the case of cloning an image of a
3TB drive onto a USB2 connected 3 or 4TB drive. If the disk in
question was 1TB or smaller, that 24 hours would suggest that the
Acronis cloning tool was struggling with bad sectors.

Such cloning tools assume that the source disk is in good working
order (FS corruption, in this case, is irrelevant unless the cloning
process is using an "Intelligent" algorithm to avoid cloning unused
space and content free files such as the windows page and hibernate
files).

If you suspect (or have run the HDD diagnostics to verify) the
existence of bad sectors, the only cloning tool you should be using is
"ddrescue", normal cloning tools are likely to get bogged down, or
even stall completely, trying to clone bad sectors (perhaps taking
weeks just to deal with a few thousand bad sectors alone, assuming the
disk doesn't fail completely by then).

ddrescue is designed to avoid time wasting on bad sectors by 'dancing
around the bad sector areas', prioritising on the remaining good areas
(usually in excess of 99% of the disk space) to retrieve the still
retrievable data, only then 'mining' the bad areas of the disk for
readable sectors that may be hidden amongst the bad block areas. Also,
ddrescue can deal with disk problems that can completey stymie the
regular cloning tools by resetting the disk if it's controller gets
into a confused state trying to read damaged tracks.

In the case of a failing disk, a 24 hour run is usually enough to
retrieve in excess of 95% of the sectors (you can terminate the
process anytime you feel you've reached the state of vanishingly small
returns on further time investment).

You can let it run indefinitely or until the HDD fails altogether
but, with ddrescue, 24 hours usually proves to be enough, any longer
to achieve a 90+% recovery is usually an indication that the drive is
in a really bad state and not worth spending an extra day or two just
to retrieve one more percent (which may or may not contain useful
data).

Obviously, a lot depends on how valuable (or priceless) the data
you're trying to recover might be but if it's _that_ valuable, you
aught to be considering the services of a professional data recovery
specialist if a 24 hour run fails to unearth the wanted data.

>
>Then I ran chkdsk. I thought I had lost a lot of files because I had a
>lot of empty folders or folders with one or two files in but I think
>what has happened is that these were deleted folders that have been
>restored by chkdsk. I found the same folders with all their files on
>my other disc, I think the folders were originally on the disc A and I
>copied them to disc B and chkdsk has found remnants on disc A and
>restored them, if that makes any sense, I know my explanation is not
>brilliant.

A straight 'sector for sector' clone will allow you to run FS check
and repair tools (CHKDSK in this case) without it suffering the
complication of bad sectors on the original disk. There might be gaps
in the data but at least you'll be able to access the files you need
which may well have remained untouched by the bad sectors issue on the
original disk.

>
>Anyway that disc seems to be back to normal now. I used to use
>Norton's disc doctor. Is that still around/recommended? I thought it
>used to be better than scandisk and chkdsk.

Which disk seems to be back to normal, the original or the newly
cloned disk?

>
>Now to fix that other disc...

If that's the original disk, I assume you're going to run its
manufacturer's diagnostic tool and try to 'repair' any bad sectors
that might be discovered. If it passes the diagnostic tests, you can
partition and high level format it for further use.

If it has less than a dozen or so repairable bad sectors, I'd be
inclined to avoid relying on it for storing valuable data without
further extensive testing. A test install of a bloatware OS such as
Vista or win7, preferably pre-SP so you can let it be subject to the
continiuous automatic updates that will mightily exercise the drive
over the following week or so, should do the trick[1]. :-)

[1] You can make an image of the freshly installed Vista or win7 so
you can 'rinse and repeat' the updating process ad nausium until
you're convinced the bad sectors were just a 'one off' event rather
than a sign of impending disk failure.
--
Regards, J B Good

[Rob Morley]

On Fri, 13 Sep 2013 07:59:56 +0100

Stephen <ste...@nowhere.com.invalid> wrote:

> At the time I had no idea what the message meant and I guessed it the
> wrong way round, thinking it was deleting files that had no
> directory. That's why I wrongly thought in my OP that it might be
> deleted files that had not been deleted properly. The problem is that
> whilst check disk is running you can't google to see what the message
> means ;)

You don't have a spare machine or three lying around? Weird. :-)

[Johny B Good]

It's more a case of 'Rolling back' the FAT/MFT to its previously
uncorrupted state when the duplicated copies fail to match due to
corruption of these FS areas.

I can explain the mechanism for FAT based FSes (NTFS and other
journaled FSes use a similar but more complex strategy). Whenever a
file is saved (either a new copy of an edited file or just simply a
new file), the FS allocates unused space for the save operation,
writes the file data into that space, updates the file's directory and
FAT entries and the free space allocation (only updating the two FATs
_after_ saving the data into free space on the disk).

This sequence of events means that, in the event of a sudden crash or
power outage, the only fatality will be, exclusively, the new or
updated file that was in the process of being saved. The interruption
canl occur during writing the data into available, not in use, space,
in which case the directory and FATs remain unaffected (no harm done
to existing data) and it will be as if the file had never been
written.

If the interuption occurs after the data was written and the FS was
in the middle of updating the directory entry and FATs, it will either
succeed with the first FAT and fail midway through the second or else
fail with the first and not touch the second copy.

In the first case, the write succeeds (but there is the issue of a
corrupted 2nd copy of the FAT lurking if a similar interruption occurs
before another file can be successfully written). In the second case,
there will be a FS corruption error that prevents reliable access to
existing files in the partition space on the HDD.

Most, if not all, editing software uses a similar approach when
saving a freshly edited file. The original file may be renamed as a
hidden scratch file or human readable backup version (extension
changed to BAK for example) which may or may not be deleted
afterwards. _before_ the new version is written to the disk.

This guarantees that the only data lost to a crash is the new data
rather than the original file itself. It's a strategy designed to
minimise the risk of data loss in common use with virtually all
editing software.

Running CHDSK /R from a command console , will usually repair such FS
errors successfully because it can determine which of the two FATs are
uncorrupted and replace the corrupted or out of date FAT with the good
copy since the writing algorithm was designed to make such crash
induced errors repairable with minimum effect on the existing file
structure in the first place.

I'm familiar with this because I had to write my own FS for a home
brewed Tape operaitng system using a hint given to me by a friend who
may or may not have been familiar with the system used by PC-DOS /
MSDOS some 3 decades ago.

In my system I called the FAT a "LNKTBL" (6 character mnemonic for
"Link Table" which is all a FAT is at heart. This is a linear table of
pointers to both, in my case, data blocks and link table entries.

Each directory entry used a single entry point into the link table
(along with the actual file size) which would have a pointer entry to
the next used data block (or a zero value to signify no further
blocks).

Free space was just simply a special hidden file pointing to the
entry point for free space (as was the Bad blocks entry created by the
formatter when it detected corrupted data blocks due to droputs on the
C60 cassette sized tape (data cassette or normal cassette types - I
was using special data cassette drives for this job). I don't recall
writing a "CHKDSK" utility to allow me to explicitly fix FS errors. I
think I just relied upon the FS to 'correct' such errrors 'on the
fly'.

The directory entries and LNKTBL nicely fitted into a single 2KB data
block which I duplicated in the middle of the tape for each side
formatted to 168 2KB data blocks - a total formatted capacity of 332KB
per side of each tape which was quite respectable compared to the
320/360 KB formats of the 40 track Floppy disks then in common use
with the IBM PC.