COLLECTED hard drive usage after XP NTFS

On Wed, 27 Sep 2006 11:28:37 -0400, "MEB" meb@not
put finger to keyboard and composed:

However you fail to address:

| Free clusters: 1,537,767 !FSInfo mismatch! = 90% free
That's a 10% differential of disk space.

Let's see where it might be:
"Tree statistic: 395 directories, 579 files, 831 KB (the kb is the
directories, not total file kb)
can still be attempted at recovery (and yes, many CAN be viewed,
" except for the encrypted/compressed files)""
INTACT files which show their original untouched names, in their original
directories (now corrupt), and holding their same locations on the hard
drive. Unmovable, unremovable - they are apparently protected from erasure.

I have no experience with NTFS or Windows XP, but I wonder if XP is
able to make use of the drive's full capacity by using LBA mode rather
than CHS. This would mean that data would eventually be written to
those logical blocks (aka sectors) at the tail end of the disc. These
sectors would be invisible to any OS that restricted itself to CHS
mode, or which honoured any BIOS imposed limitation. However, a
forensic sector editor would still be able to read them.

I don't understand how 10% of the disc could become inaccessible,
though.

I'd be keen to see the CHS numbers in a BIOS HD Autodetect screen, as
well as the CHS numbers in an MBRtool report. If you can post the
actual raw contents of the partition table, then that may be
interesting, too.

This is how my 13GB HD looks:
http://groups.google.com/group/micro...e=source&hl=en

Note that I have yet to partition the last half of my drive. I'm
reserving this area for Linux ... if I ever get around to it.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

Franc Zabkar wrote:
On Wed, 27 Sep 2006 11:28:37 -0400, "MEB" meb@not
put finger to keyboard and composed:

However you fail to address:

| Free clusters: 1,537,767 !FSInfo mismatch! = 90% free
That's a 10% differential of disk space.

Let's see where it might be:
"Tree statistic: 395 directories, 579 files, 831 KB (the kb is the
directories, not total file kb)
can still be attempted at recovery (and yes, many CAN be viewed,
" except for the encrypted/compressed files)""
INTACT files which show their original untouched names, in their original
directories (now corrupt), and holding their same locations on the hard
drive. Unmovable, unremovable - they are apparently protected from erasure.

I have no experience with NTFS or Windows XP, but I wonder if XP is
able to make use of the drive's full capacity by using LBA mode rather
than CHS. This would mean that data would eventually be written to
those logical blocks (aka sectors) at the tail end of the disc. These
sectors would be invisible to any OS that restricted itself to CHS
mode, or which honoured any BIOS imposed limitation. However, a
forensic sector editor would still be able to read them.

I don't understand how 10% of the disc could become inaccessible,
though.

I'd be keen to see the CHS numbers in a BIOS HD Autodetect screen, as
well as the CHS numbers in an MBRtool report. If you can post the
actual raw contents of the partition table, then that may be
interesting, too.

This is how my 13GB HD looks:
http://groups.google.com/group/micro...e=source&hl=en

Note that I have yet to partition the last half of my drive. I'm
reserving this area for Linux ... if I ever get around to it.

- Franc Zabkar

Interesting Franc. Linux intrigues me as well and I am someday looking
forward to trying it out as well. In addition, I think I will try out
Apple and see how their technology compares since I like to be
well-rounded in technology. The Ipod Mini with Apple is so sweet in my
opinion and I just love having a collection of around 50 songs that were
available for purchase for just a buck a piece.

Johnny, please snip when the posts get super long. It get old scrolling
down so far and thanks I really appreciate your comments.

Another long one for the discussion (theory)::

"Franc Zabkar" wrote in message
...
| On Wed, 27 Sep 2006 11:28:37 -0400, "MEB" meb@not
| put finger to keyboard and composed:
|
| However you fail to address:
|
| | Free clusters: 1,537,767 !FSInfo mismatch! = 90% free
| That's a 10% differential of disk space.
|
| Let's see where it might be:
| "Tree statistic: 395 directories, 579 files, 831 KB (the kb is the
| directories, not total file kb)
| can still be attempted at recovery (and yes, many CAN be viewed,
| " except for the encrypted/compressed files)""
| INTACT files which show their original untouched names, in their
original
| directories (now corrupt), and holding their same locations on the hard
| drive. Unmovable, unremovable - they are apparently protected from
erasure.
|
| I have no experience with NTFS or Windows XP, but I wonder if XP is
| able to make use of the drive's full capacity by using LBA mode rather
| than CHS. This would mean that data would eventually be written to
| those logical blocks (aka sectors) at the tail end of the disc. These
| sectors would be invisible to any OS that restricted itself to CHS
| mode, or which honoured any BIOS imposed limitation. However, a
| forensic sector editor would still be able to read them.

My guess would be as you suggest, XP NTFS makes full use of the disk and
then some.
CHS changes are made when installing the OS, by the OS.
--
Yes, a quality forensic editor can access and read the extra sectors. You
can even change the CHS within some of them beyond the disk's stated
capacity, hence every part of the disk is potentially accessible.

|
| I don't understand how 10% of the disc could become inaccessible,
| though.

Remember we're dealing with a small hard drive. Were this a 30 gig or more,
would we really notice 5 or 7 hundred megs of lost space? On a 300+ gig,
would we really notice loss of a gig. Particularly as most tools would show
these areas as "bad sectors" because they couldn't access them.

Think of it like this:
These are mostly DOS based tools. DOS can NOT read or recognize dozens of
file systems, partitions, file types, etc., everyone knows that.
The other tools created to address these activities (wiping, formatting,
fdisking, etc) base their information and coding on known partition types,
and file (system) "indicators" (hex coding if you will). Many of them
respect BIOS limitations, CHS, and HPA.

What happens when they attempt to access unknown files, partitions, filing
systems, or file indicators?

Let's pull some information from a related activity.

From the "Eraser 5.8" (http://www.heidi.ie/eraser/ -
http://www.tolvanen.com/sami/) help file (a nice little erasing tool BTW):

__ QUOTE (excerpt)__

The special cases when erasing data by overwriting may not be desirable when
alternative methods should be used or when there are important matters that
need to be considered first are discussed here.

Compressed Files

You can safely erase files compressed at the file system level (file
compression requires a file system that supports it, such as NTFS). When
erasing compressed files on Windows NT or 2000, Administrator privileges are
required for low-level disk access.

Files compressed with an external application, such as ZIP files, can
naturally be erased.

If you are erasing files from a partition compressed with external
compression software (such as DriveSpace), use only pseudorandom data for
overwriting.

Compressed Drives

Files and unused space on a compressed NTFS partition can be erased
normally.

However, if your partition is compressed with external compression software
(such as DriveSpace), the following details should be considered. In
general, one should avoid storing sensitive data on a partition compressed
with external software.

Turn off cluster tip erasing for partitions that are compressed with
external software, erasing cluster tips will confuse the application that
handles the compressing and may result to dramatic loss of disk space. If
you erased cluster tips on a compressed drive and lost significant amount of
disk space, you must recompress the drive to restore the lost space.

You should use only pseudorandom data when overwriting unused space on a
partition compressed with external software, the other methods include
passes that are of highly compressible data and should not be used. Your
computer may slow down and even stop responding because the written data is
being compressed.

Files saved on the compressed drive can also be overwritten taking the
aforementioned matters into consideration.

Encrypted Files

You can safely erase files encrypted at the file system level (file
compression requires a file system that supports it). Files encrypted with
an external application, such as Pretty Good Privacy (PGP), can be erased as
well.

As the data is already stored in unreadable format, erasing is not required,
but usually increases security.

Encrypted Drives

In general, one should not erase the unused disk space on an encrypted drive
(the same applies to encrypted virtual drives, such as the ones created by
PGPDisk, ScramDisk or E4M).

The erasing will be useless because the data saved on the drive is encrypted
into unreadable format, erasing may slow down your computer and it may even
stop responding, depending on the driver that handles encryption.

Files on the encrypted drives can be overwritten, but this should be avoided
because of the reasons mentioned above.
_--END QUOTE

Pursuant the above, the "ORIGINAL SYSTEM OR PROGRAM" must/should be used
to access compressed and or encrypted data areas.
A somewhat misleading statement indicates "compressed NTFS partition can be
erased normally." The other statements must be taken into account. They may
be address "normally" THROUGH the ORIGINAL/CREATING operating system/program
(save special circumstances), so the other statements must be read as
including necessity of XP system to address XP partitions/ hidden/
protected/ encrypted/ compressed hard drives and various areas XP NTFS
creates. It also states: "Administrator privileges are required for
low-level disk access." so the system monitors access. Or is it something
else?

ERASER is a Windows program for both 98 and XP, hence when used in XP it
can address these areas of the disk BECAUSE it is working within the
"creator" environment.
Note this: " If you erased cluster tips on a compressed drive and lost
significant amount of disk space, you must recompress the drive to restore
the lost space."
So what is it we have been doing with all these DOS based tools?
http://mirror.href.com/thestarman/asm/mbr/FDISK98.htm for fdisk
http://mirror.href.com/thestarman/asm/mbr/FORMAT98.htm for format
http://mirror.href.com/thestarman/asm/mbr/MSWIN41.htm for boot record/sector
http://mirror.href.com/thestarman/asm/mbr/95BMEMBR.htm for MBR

Let's say not the whole disk is compressed (though it basically is in
NTFS), but only certain areas of the disk. What happens when we attempt to
remove them normally? What happens if more than one compression and or
encryption scheme is used within the disk, e.g. compression within
compression or encryption within compression?

Now what happens if HPA is involved in protecting certain areas of the
disk, such as some of those compressed areas or files?
Now what happens when we use tools that "don't know Jack" about what XP
NTFS has done to the disk?

Perhaps now you can grasp why I'd like that information on XP NTFS.

|
| I'd be keen to see the CHS numbers in a BIOS HD Autodetect screen, as
| well as the CHS numbers in an MBRtool report. If you can post the
| actual raw contents of the partition table, then that may be
| interesting, too.

Most of that will not be worth anything.
If you have used these tools, you know everything (except the BIOS HD
SCREEN) you just asked for has already been modified extensively, many times
over. [The web pages will show some of the activity when they are created.]
Meandisk, for instance, uses the DEBUG MBR reset for the disk in addition
to it's complete zero wipe (which doesn't work).

The only thing of any real value would be the $Mft tables (that are still
intact) and one of the backup boot sectors. However, the backup boot and
partition table have also been changed.
Or have they?
Running TESTDISK !Search (extended search - searches the entire disk) pulls
up the NTFS partition information. However, placing that info as the
partition, causes the disk to extend far beyond it's stated CHS capacity. So
perhaps LBA is used in non-standard areas of the disk.
The first few times a backup partition table was used or viewed, it was
similar to the CHS of the disk, except for one cylinder less. That was wiped
by one of the tools, yet this other one still pops up.

Using a disk editor shows a large amount of information stored beyond the
CHS end boundary of the disk, including what appears to be a partition table
and a boot sector.grin

|
| This is how my 13GB HD looks:
|
http://groups.google.com/group/micro...e=source&hl=en
|
| Note that I have yet to partition the last half of my drive. I'm
| reserving this area for Linux ... if I ever get around to it.
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.

Well I commend you on installing Linux. Once you get used to it,
particularly if you liked command mode DOS, you will like it. A very
powerful OS. Still a little lacking on "Window like glitse", but it's users
love it largely because it doesn't "dumb you down". I think you will too.

--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"

"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________

MEB wrote:
Another long one for the discussion (theory)::

"Franc Zabkar" wrote in message
...
| On Wed, 27 Sep 2006 11:28:37 -0400, "MEB" meb@not
| put finger to keyboard and composed:
|
| However you fail to address:
|
| | Free clusters: 1,537,767 !FSInfo mismatch! = 90% free
| That's a 10% differential of disk space.
|
| Let's see where it might be:
| "Tree statistic: 395 directories, 579 files, 831 KB (the kb is the
| directories, not total file kb)
| can still be attempted at recovery (and yes, many CAN be viewed,
| " except for the encrypted/compressed files)""
| INTACT files which show their original untouched names, in their
original
| directories (now corrupt), and holding their same locations on the hard
| drive. Unmovable, unremovable - they are apparently protected from
erasure.
|
| I have no experience with NTFS or Windows XP, but I wonder if XP is
| able to make use of the drive's full capacity by using LBA mode rather
| than CHS. This would mean that data would eventually be written to
| those logical blocks (aka sectors) at the tail end of the disc. These
| sectors would be invisible to any OS that restricted itself to CHS
| mode, or which honoured any BIOS imposed limitation. However, a
| forensic sector editor would still be able to read them.

My guess would be as you suggest, XP NTFS makes full use of the disk and
then some.
CHS changes are made when installing the OS, by the OS.
--
Yes, a quality forensic editor can access and read the extra sectors. You
can even change the CHS within some of them beyond the disk's stated
capacity, hence every part of the disk is potentially accessible.

|
| I don't understand how 10% of the disc could become inaccessible,
| though.

Remember we're dealing with a small hard drive. Were this a 30 gig or more,
would we really notice 5 or 7 hundred megs of lost space? On a 300+ gig,
would we really notice loss of a gig. Particularly as most tools would show
these areas as "bad sectors" because they couldn't access them.

Think of it like this:
These are mostly DOS based tools. DOS can NOT read or recognize dozens of
file systems, partitions, file types, etc., everyone knows that.
The other tools created to address these activities (wiping, formatting,
fdisking, etc) base their information and coding on known partition types,
and file (system) "indicators" (hex coding if you will). Many of them
respect BIOS limitations, CHS, and HPA.

What happens when they attempt to access unknown files, partitions, filing
systems, or file indicators?

Let's pull some information from a related activity.

From the "Eraser 5.8" (http://www.heidi.ie/eraser/ -
http://www.tolvanen.com/sami/) help file (a nice little erasing tool BTW):

__ QUOTE (excerpt)__

The special cases when erasing data by overwriting may not be desirable when
alternative methods should be used or when there are important matters that
need to be considered first are discussed here.

Compressed Files

You can safely erase files compressed at the file system level (file
compression requires a file system that supports it, such as NTFS). When
erasing compressed files on Windows NT or 2000, Administrator privileges are
required for low-level disk access.

Files compressed with an external application, such as ZIP files, can
naturally be erased.

If you are erasing files from a partition compressed with external
compression software (such as DriveSpace), use only pseudorandom data for
overwriting.

Compressed Drives

Files and unused space on a compressed NTFS partition can be erased
normally.

However, if your partition is compressed with external compression software
(such as DriveSpace), the following details should be considered. In
general, one should avoid storing sensitive data on a partition compressed
with external software.

Turn off cluster tip erasing for partitions that are compressed with
external software, erasing cluster tips will confuse the application that
handles the compressing and may result to dramatic loss of disk space. If
you erased cluster tips on a compressed drive and lost significant amount of
disk space, you must recompress the drive to restore the lost space.

You should use only pseudorandom data when overwriting unused space on a
partition compressed with external software, the other methods include
passes that are of highly compressible data and should not be used. Your
computer may slow down and even stop responding because the written data is
being compressed.

Files saved on the compressed drive can also be overwritten taking the
aforementioned matters into consideration.

Encrypted Files

You can safely erase files encrypted at the file system level (file
compression requires a file system that supports it). Files encrypted with
an external application, such as Pretty Good Privacy (PGP), can be erased as
well.

As the data is already stored in unreadable format, erasing is not required,
but usually increases security.

Encrypted Drives

In general, one should not erase the unused disk space on an encrypted drive
(the same applies to encrypted virtual drives, such as the ones created by
PGPDisk, ScramDisk or E4M).

The erasing will be useless because the data saved on the drive is encrypted
into unreadable format, erasing may slow down your computer and it may even
stop responding, depending on the driver that handles encryption.

Files on the encrypted drives can be overwritten, but this should be avoided
because of the reasons mentioned above.
_--END QUOTE

Pursuant the above, the "ORIGINAL SYSTEM OR PROGRAM" must/should be used
to access compressed and or encrypted data areas.
A somewhat misleading statement indicates "compressed NTFS partition can be
erased normally." The other statements must be taken into account. They may
be address "normally" THROUGH the ORIGINAL/CREATING operating system/program
(save special circumstances), so the other statements must be read as
including necessity of XP system to address XP partitions/ hidden/
protected/ encrypted/ compressed hard drives and various areas XP NTFS
creates. It also states: "Administrator privileges are required for
low-level disk access." so the system monitors access. Or is it something
else?

ERASER is a Windows program for both 98 and XP, hence when used in XP it
can address these areas of the disk BECAUSE it is working within the
"creator" environment.
Note this: " If you erased cluster tips on a compressed drive and lost
significant amount of disk space, you must recompress the drive to restore
the lost space."
So what is it we have been doing with all these DOS based tools?
http://mirror.href.com/thestarman/asm/mbr/FDISK98.htm for fdisk
http://mirror.href.com/thestarman/asm/mbr/FORMAT98.htm for format
http://mirror.href.com/thestarman/asm/mbr/MSWIN41.htm for boot record/sector
http://mirror.href.com/thestarman/asm/mbr/95BMEMBR.htm for MBR

Let's say not the whole disk is compressed (though it basically is in
NTFS), but only certain areas of the disk. What happens when we attempt to
remove them normally? What happens if more than one compression and or
encryption scheme is used within the disk, e.g. compression within
compression or encryption within compression?

Now what happens if HPA is involved in protecting certain areas of the
disk, such as some of those compressed areas or files?
Now what happens when we use tools that "don't know Jack" about what XP
NTFS has done to the disk?

Perhaps now you can grasp why I'd like that information on XP NTFS.

|
| I'd be keen to see the CHS numbers in a BIOS HD Autodetect screen, as
| well as the CHS numbers in an MBRtool report. If you can post the
| actual raw contents of the partition table, then that may be
| interesting, too.

Most of that will not be worth anything.
If you have used these tools, you know everything (except the BIOS HD
SCREEN) you just asked for has already been modified extensively, many times
over. [The web pages will show some of the activity when they are created.]
Meandisk, for instance, uses the DEBUG MBR reset for the disk in addition
to it's complete zero wipe (which doesn't work).

The only thing of any real value would be the $Mft tables (that are still
intact) and one of the backup boot sectors. However, the backup boot and
partition table have also been changed.
Or have they?
Running TESTDISK !Search (extended search - searches the entire disk) pulls
up the NTFS partition information. However, placing that info as the
partition, causes the disk to extend far beyond it's stated CHS capacity. So
perhaps LBA is used in non-standard areas of the disk.
The first few times a backup partition table was used or viewed, it was
similar to the CHS of the disk, except for one cylinder less. That was wiped
by one of the tools, yet this other one still pops up.

Using a disk editor shows a large amount of information stored beyond the
CHS end boundary of the disk, including what appears to be a partition table
and a boot sector.grin

|
| This is how my 13GB HD looks:
|
http://groups.google.com/group/micro...e=source&hl=en
|
| Note that I have yet to partition the last half of my drive. I'm
| reserving this area for Linux ... if I ever get around to it.
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.

Well I commend you on installing Linux. Once you get used to it,
particularly if you liked command mode DOS, you will like it. A very
powerful OS. Still a little lacking on "Window like glitse", but it's users
love it largely because it doesn't "dumb you down". I think you will too.


It certainly seems that Linux is an operating system that I should
install on this machine. Anyway, thanks for the input MEB. Wow, I
sometimes wonder if the 98 general newsgroup has one of the most
technical newsgroups that is out there within the Microsoft newsgroups.

Dan wrote:
Johnny, please snip when the posts get super long. It get old scrolling
down so far and thanks I really appreciate your comments.
Interesting, I just opened vgx.dll in Wordpad and then tried cutting and
pasting some of the vgx.dll file to this newsgroup and I was unsuccessful.

Finding the correct hard drive space (total number of sectors) is all that
matters. In most any large capacity drive the firmware will have remapped
some reserved sectors over identified bad sectors, and that might tell you
something about the health of the drive in the same way that the SMART
reporting tools can reveal similar detail. It's not relevant to your claim
that clearing the first few sectors of the drive is not sufficient to force
NTFS to give back all the space originally allocated to it.

Scandisk and Format operate at the file system level, and any bad sector
identification they do is relevant to the file system only. Other utilities
can make more permanent identification of bad or suspect sectors, and in
some cases these can cause problems. Some procedures for marking suspect
sectors as bad interferes with the inbuilt sector remapping routines and
causes the disk to use up all its reserved sectors trying to restore
corrupted sectors that never were really bad in the first place. This is
the result of using unsuitable tools, and has nothing to do with XP or NTFS.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"MEB" meb@not wrote in message
...
Well fine, then you do have disks available, use a quality forensic tool
on
them. Now we're getting somewhere.

Merely finding full hard drive space means relatively little, since there
are reserved sectors for S.M.A.R.T. activity AND other
scandisk/fdisk/format like activities. The disk will use these areas
attempting to replace inaccessible areas of the disk. That does NOT mean
they are bad, just inaccessible.

--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"

"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as
if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________

"Jeff Richards" wrote in message
...
| Why? I know that the forensic tools will be able to find data - I've
used
| them to do just that. I know that some tools will be able to identify
the
| original partitioning as NTFS, because they can recognise certain
| signatures. But I also know, because I've already done it, that when
the
| disk is partitioned I will get full access.
|
| And I also know that after using ZAP or WIPE and then FDISK and Format I
| will sometimes get bad sectors reported. That's what I expected, since
in
| those cases the reason for rebuilding the disk was that the
manufacturer's
| diagnostic told me that there were bad sectors developing. And that's
why
| some of these disks are lying around here (including a near new Maxtor
80Gb
| that's going back under warranty). But the bad sectors had nothing to do
| with the attempts that I made at recovery. They were there before I
started,
| although not always reported to the operating system as such.
| --
| Jeff Richards
| MS MVP (Windows - Shell/User)
| "MEB" meb@not wrote in message
| ...
|
|
| "Jeff Richards" wrote in message
| ...
| | "MEB" meb@not wrote in message
| | ...
| | snip
| |
| | There are hundreds (thousands) of web pages which appear to claim
XP
| NTFS
| | is capable of being removed via old techniques and tools.
| | My testing (to date) shows this in not true. Several hundred
megabytes
| of
| | hard drive space (on these small hard drives, who knows how much
on
| larger
| | drives) still contain files and folders from an XP NTFS
installation
| after
| | its removal.
| |
| | You are addressing an issue completely different than the original
| topic.
| No
| | part of that discussion referred to removing all trace of NTFS. The
| point
| | of recommending ZAP or WIPE was to enable Windows 98 FDISK to work.
| Nothing
| | you have mentioned here indicates in any way that ZAP or WIPE will
not
| work
| | for that purpose, or will damage the disk in any way. Check the
| description
| | for these utilities - they both clearly specifiy exactly how much of
the
| | disk gets overwritten. In terms of current disk sizes, it's not
much.
| But
| it
| | is enough to enable FDISK to partition the disk as FAT32, which was
the
| | point of the original query.
| |
| | The fact that recovery utilities can see part of the old NTFS data
after
| | running something like ZAP or WIPE is simply not relevant. They
will
| | probably still be able to see the data after FDISK has partitioned
the
| | drive, and possibly even after it's formatted (depending on the
options
| | used). This old, recoverable data has absolutely no impact on
| subsequent
| | use of the disk. It will get overwritten as the disk fills up.
| |
| | I suspect the problems you are seeing are due to data recovery or
disk
| | inspection tools you are using which are somehow protecting data
that
| | appears to be recoverable. Without knowing the exact sequence of
| utilities
| | you used it's impossible to say what has happened. But I have many
| disks
| | scattered around many different clients that have had NTFS removed
as
| part
| | of the process of reconditioning second hand-machines, and I have
never
| had
| | any problems getting access to the full capacity of the disk.
Provided,
| of
| | course, I configured them correctly and used a file system that was
| capable
| | of accessing that capacity.
| |
| | And to suggest that no results to your searching proves that there's
a
| | conspiracy to keep the problem quiet is just nonsense.
| | --
| | Jeff Richards
| | MS MVP (Windows - Shell/User)
| |
| |
| |
| |
|
| I note you state you have disks laying around which have been wiped
for
| re-use.
| Could you use forensic tools to look for compressed and encrypted
files
on
| those disks?
| I know that's a lot to ask, your day is probably full, but it would be
| instrumental in my research, and this thread.
| Make sure the tool or tools have access to the full disk and are NOT
| limited by supposed $ BAD SECTOR $ classifications, such as would be
| created
| during fdisking and formatting, and scandisking after a "wipe".
|
| --
| MEB
| http://peoplescounsel.orgfree.com/
| BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
| world"
|
| "Most people, sometime in their lives, stumble across truth.
| Most jump up, brush themselves off, and hurry on about their business
as
| if
| nothing had happen." Winston Churchill
| Or to put it another way:
| Morpheus can offer you the two pills;
| but only you can choose whether you take the red pill or the blue one.
| _______________
|
|
| |
| |
|
|
|
|

"Franc Zabkar" wrote in message
...
On Tue, 26 Sep 2006 16:28:12 -0400, "MEB" meb@not
put finger to keyboard and composed:

Hard disk 1
Total capacity: 7,003,586,560 bytes = 6.5 GB
Number of cylinders: 851
Number of heads: 255
Sectors per track: 63
Bytes per sector: 512
Sector count: 13,678,880
Surplus sectors at end: 7,565

Partition 1
Sectors 63 - 13,655,249
Partition table: Sector 0
File system: FAT32

I've checked two of my PCs. Neither has ever seen NTFS or Win XP, yet
the hard drives in both machines show a usable capacity that is
slightly less than their native capacity. In all cases it is the BIOS
(not Fdisk, sorry) that reserves the last cylinder for its own use,
whatever that may be. In addition, there is the loss of the surplus
sectors that result from the translation to CHS mode. This is because
the BIOS tries to fit the drive's geometry into 1024 cylinders or
less. In so doing, the last cylinder is often only partially filled,
so its surplus sectors are discarded. The next full cylinder is then
reserved.

In short, I see the same behaviour in a DOS/Win9x system, so it is
clearly not an XP/NTFS phenomenon.

BTW, I'm using MBRtool to view the MBR and partition table, both in
raw hex mode and in decoded mode.

http://www.diydatarecovery.nl/downloads/MBRtool.zip

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

A couple of years back, noticed similar symptom when simply changing from
auto to user settings for the only hard drive onboard. I did not change the
"user" settings it provided in the switch. The layout change was
significant enough for filename change problems and so forth. Award bios.
Think you're on to something.
--
Jonny

"MEB" meb@not wrote in message
...


Look again below then re-think what you presented.

"Jonny" wrote in message
...
| "MEB" meb@not wrote in message
| ...
| SYNOPSIS:
|
| This is a collected discussion concerning XP hard drive re-use, in
which
I
| have personally participated, per [there may be others which I have
| missed]:
|
| " IBM T22 and Win 98se";
| " New post, ms Everest report";
| " Hangs on POST screen";
| " win 98 installation"
| " Updates for Win9X's & reason/logic"
| " No hard drive?"
| " Unable to install Win98 SE"
| " PC100 v PC133 ram"
|

[slashed information]

|
| Tools tested so far:
|
| hd-util [Samsung];
| SH-diag [Samsung];
| Sutil [Samsung];
| Meandisk;
| DBan;
| Wipe;
| Zap;
| HDAT2;
| AEFDISK;
| GDISK (Symantec);
| Killdisk;
| BootitNG;
| MBRWork;
| PowerMax [Maxtor];
| Maxtor MaxBlast;
| Super FDisk;
| MHDD;
| OnTrack Data Advisor;
| Seagate SeaTools;
| Eraser;
| Testdisk;
| WinHex.
| (may already have used several others)
|
| Microsoft tools used:
| CHKDISK (and its autochkdsk - XP versions);
| Recovery Console;
| Delpart;
| fdisk;
| format;
|
| ISSUES:
|
| There are hundreds (thousands) of web pages which appear to claim XP
NTFS
| is capable of being removed via old techniques and tools.

[slashed information]

| No, not trying to recover anything except the full hard drive and
remove
| XP
| NTFS completely. Consider it like returning the hard drive to it's
| pristine
| state without the contamination and loss of space, and potential
failures
| which may be caused pursuant the corruption.
|
| --
| MEB
| _______________
|
|
|
| Yes there are software tools for finding files after the mbr and
partition
| (along with the file system table) are wiped. Writing zeroes to the
entire
| drive has been adequate for me using the utility from the hard drive
maker.
| There's others that go beyond that and write zeroes and ones multiple
times.
| --
| Jonny
|
|

I think you'll find that those tools I referenced do exactly as you've
stated and far more.

Unless you've done a forensic analysis of the disk(s) (that's actually
check it), you know no more that what you BELIEVE to be true, quite
possibly
what you read somewhere as well.

Think of it like "there are weapons of mass destruction in Iraq" and "they
are months away from nuclear weapons". It's about as accurate.



The only "tools" I've used are the MS ones, and those provided by WD
website, the IBM tools, and Maxtors. The ITs in the US Navy told me about a
program that they used to clean hard drives (multiple zeroes and ones).

All I know is from my own experiences, hands on stuff. That is what I deem
most true for myself. I suspect that may be true for you as well.
--
Jonny

"Jonny" wrote in message
...
| "MEB" meb@not wrote in message
| ...
|
|
| Look again below then re-think what you presented.
|
| "Jonny" wrote in message
| ...
| | "MEB" meb@not wrote in message
| | ...
| | SYNOPSIS:
| |
| [slashed information]
|
| |
| | Tools tested so far:
| |
| | hd-util [Samsung];
| | SH-diag [Samsung];
| | Sutil [Samsung];
| | Meandisk;
| | DBan;
| | Wipe;
| | Zap;
| | HDAT2;
| | AEFDISK;
| | GDISK (Symantec);
| | Killdisk;
| | BootitNG;
| | MBRWork;
| | PowerMax [Maxtor];
| | Maxtor MaxBlast;
| | Super FDisk;
| | MHDD;
| | OnTrack Data Advisor;
| | Seagate SeaTools;
| | Eraser;
| | Testdisk;
| | WinHex.
| | (may already have used several others)
| |
| | Microsoft tools used:
| | CHKDISK (and its autochkdsk - XP versions);
| | Recovery Console;
| | Delpart;
| | fdisk;
| | format;
| |
| | ISSUES:
| |
| | There are hundreds (thousands) of web pages which appear to claim XP
| NTFS
| | is capable of being removed via old techniques and tools.
|
| [slashed information]
| | --
| | MEB
| | _______________
| |
| |
| |
| | Yes there are software tools for finding files after the mbr and
| partition
| | (along with the file system table) are wiped. Writing zeroes to the
| entire
| | drive has been adequate for me using the utility from the hard drive
| maker.
| | There's others that go beyond that and write zeroes and ones multiple
| times.
| | --
| | Jonny
| |
| |
|
| I think you'll find that those tools I referenced do exactly as you've
| stated and far more.
|
| Unless you've done a forensic analysis of the disk(s) (that's actually
| check it), you know no more that what you BELIEVE to be true, quite
| possibly
| what you read somewhere as well.
|
| Think of it like "there are weapons of mass destruction in Iraq" and
"they
| are months away from nuclear weapons". It's about as accurate.
|
|
|
| The only "tools" I've used are the MS ones, and those provided by WD
| website, the IBM tools, and Maxtors. The ITs in the US Navy told me about
a
| program that they used to clean hard drives (multiple zeroes and ones).
|
| All I know is from my own experiences, hands on stuff. That is what I
deem
| most true for myself. I suspect that may be true for you as well.
| --
| Jonny
|
|

Obviously I would have to agree, our experiences form our opinions on most
of what we believe. It isn't until we challenge those beliefs and opinions
that we can really expand our knowledge.
I would presume that what you were directed to by the Navy ITs (depending
upon the time period) revolved around tools which complied with wiping
standards such as:
One pass zeros
One pass random
US DoD 5220.22M
US DoD 5200.28
German VSITR
Russian GOST p-50739-95
Gutmann
or modifications of these or others.

--
MEB
http://peoplescounsel.orgfree.com/
BLOG http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"

"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________