"Joep" <j o e p @ d i y d a t a r e c o v e r y . n l> wrote in message news:a1d25$40578d76$3eddca68$(E-Mail Removed)-service-com
> "Ken1" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)
> > With DIY DataRecovery
> > I can scan the disk to find the NTFS partition and start the
> > recovery but the progress bar stays on 0% all the time.
>
> > The program also says Filesystem type is: Not known so far during
> > that time, even it it earlier found the partition info when scanning.
>
> iRecover doesn't rely on the file system type that was recorded in the
> partition table, after all it may concern a FAT32 partition that was
> accidentally formatted NTFS.

That still doesn't explain the conflicting info.
It would then be a NTFS partition and not a Fat32 partition.

>
> Joep

It's not conflicting info, it's a conflicting situation:

In the partition table it would say NTFS, however the file system you want
to recover from would be FAT32. As iRecover scan the partition it will find
more and more evidence that the data actually present corresponds with a FAT
type partition (assuming the partition was formatted in error and no data
was written to it yet).

As long as iRecover hasn't decided on the file system yet, it will say the
file system is unknown EVEN when it says NTFS in the partition table. For
this part of the analysis it's irrelevant what the file system is as
iRecover will collect all possible components regardless if they're FAT or
NTFS type components.

Then when it has decided on the file system, and for arguments sake, this is
FAT32, it will say so, again EVEN when the partition table says NTFS.

If the situation is too conflicting the user can specify in advance that the
file system is FAT/NTFS. This may be required for example if data was
written to the partition formatted in error, or when a tool like
PartitionMagic is frequently used to move and convert partitions (PM doesn't
"clean up" when for example moving a partition). But even then, during the
collection phase the file system is 'unknown'. In the end, although the user
selected FAT, there may not be enough data found to allow recovery from the
F.U.B.A.R. FAT partition

Joep

--
D I Y D a t a R e c o v e r y . N L - Data & Disaster Recovery Tools

http://www.diydatarecovery.nl
http://www.diydatarecovery.com

Please include previous correspondence!

DiskPatch - MBR, Partition, boot sector repair and recovery.
iRecover - FAT, FAT32 and NTFS data recovery.
MBRtool - Freeware MBR backup and restore.
CHK-Mate - automated CHK file analysis & recovery


"Folkert Rienstra" <see_reply-(E-Mail Removed)> wrote in message
news:c3ac15$25sgf2$(E-Mail Removed)...
> "Joep" <j o e p @ d i y d a t a r e c o v e r y . n l> wrote in message
news:a1d25$40578d76$3eddca68$(E-Mail Removed)-service-com
> > "Ken1" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)
> > > With DIY DataRecovery
> > > I can scan the disk to find the NTFS partition and start the
> > > recovery but the progress bar stays on 0% all the time.
> >
> > > The program also says Filesystem type is: Not known so far during
> > > that time, even it it earlier found the partition info when scanning.
> >
> > iRecover doesn't rely on the file system type that was recorded in the
> > partition table, after all it may concern a FAT32 partition that was
> > accidentally formatted NTFS.
>
> That still doesn't explain the conflicting info.
> It would then be a NTFS partition and not a Fat32 partition.
>
> >
> > Joep

More fool you.

"Folkert Rienstra" <see_reply-(E-Mail Removed)> wrote in message news:c37ie3$24havr$(E-Mail Removed)...
> I wouldn't trust someone's software much when that person can't even setup
> his newsclient correctly to make a proper post.
>
> "Jan van Wijk" <(E-Mail Removed)> wrote in message news:W1d6fUB5m4qH-pn2-vbZOGpeKoqHi@merlin
> > On Sat, 21 Feb 2004 23:06:03 UTC, (E-Mail Removed) (Ken1) wrote:
> >
> > > I have a HD with a single NTFS partion which have lost the
> > > partition table info because of corrupt sectors/blocks.
> >
>
> [snip]
>
> >
> > Note the description of the "-b:1" parameter, which will make the
> > CLONE
> > quite slow (many hours) but will result in the minimum number of
> > sectors
> > being skipped as bad-sectors.
> >
>
> [snip]
>
> > Regards, JvW

So how does the FATxx designation get itself in the partition table,
if not by the formatting operation?

"Joep" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)
> It's not conflicting info, it's a conflicting situation:
>
> In the partition table it would say NTFS, however the file system you want
> to recover from would be FAT32. As iRecover scan the partition it will find
> more and more evidence that the data actually present corresponds with a FAT
> type partition (assuming the partition was formatted in error and no data
> was written to it yet).
>
> As long as iRecover hasn't decided on the file system yet, it will say the
> file system is unknown EVEN when it says NTFS in the partition table.
> For this part of the analysis it's irrelevant what the file system is as
> iRecover will collect all possible components regardless if they're FAT or
> NTFS type components.
>
> Then when it has decided on the file system, and for arguments sake, this is
> FAT32, it will say so, again EVEN when the partition table says NTFS.
>
> If the situation is too conflicting the user can specify in advance that the
> file system is FAT/NTFS. This may be required for example if data was
> written to the partition formatted in error, or when a tool like
> PartitionMagic is frequently used to move and convert partitions (PM doesn't
> "clean up" when for example moving a partition). But even then, during the
> collection phase the file system is 'unknown'. In the end, although the user
> selected FAT, there may not be enough data found to allow recovery from the
> F.U.B.A.R. FAT partition
>
> Joep
>
>
> "Folkert Rienstra" <see_reply-(E-Mail Removed)> wrote in message
> news:c3ac15$25sgf2$(E-Mail Removed)...
> > "Joep" <j o e p @ d i y d a t a r e c o v e r y . n l> wrote in message
> news:a1d25$40578d76$3eddca68$(E-Mail Removed)-service-com
> > > "Ken1" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)
> > > > With DIY DataRecovery
> > > > I can scan the disk to find the NTFS partition and start the
> > > > recovery but the progress bar stays on 0% all the time.
> > >
> > > > The program also says Filesystem type is: Not known so far during
> > > > that time, even it it earlier found the partition info when scanning.
> > >
> > > iRecover doesn't rely on the file system type that was recorded in the
> > > partition table, after all it may concern a FAT32 partition that was
> > > accidentally formatted NTFS.
> >
> > That still doesn't explain the conflicting info.
> > It would then be a NTFS partition and not a Fat32 partition.
> >
> > >
> > > Joep

"Folkert Rienstra" <see_reply-(E-Mail Removed)> wrote in message
> > >
> > > That still doesn't explain the conflicting info.
> > > It would then be a NTFS partition and not a Fat32 partition.

- Situation: FAT32 drive, all's well.

- Accident: FAT32 drive is formatted NTFS

- Problem: File system is now NTFS according to partition table
HOWEVER the file system more interesting for analysis is FAT32;
iRecover should treat this as a FAT32 drive rather than an NTFS one.

The conflicting info is, that while the partition table says NTFS,
we're not interested in NTFS data structures, we're interested IN FAT
data structures.

--
Joep

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In article <c3tb0b$20ar2t$(E-Mail Removed)>,
Folkert Rienstra <(E-Mail Removed)> top-posted (grr):
>"Joep" <(E-Mail Removed)> top-posted (grr) in message
>news:(E-Mail Removed)
>> In the partition table it would say NTFS, however the file system you want
>> to recover from would be FAT32. As iRecover scan the partition it will find
>> more and more evidence that the data actually present corresponds with a FAT
>> type partition (assuming the partition was formatted in error and no data
>> was written to it yet).
>
>So how does the FATxx designation get itself in the partition table,
>if not by the formatting operation?

Info on what type of filesystem is (supposedly) in a given partition is
stored in the partition table. Some partitioning tools (such as Linux's
fdisk) let you change this information without resizing partitions or
writing new filesystems to those partitions. You could start from a Linux
boot floppy or CD, change the ID for a partition from FAT32 to NTFS (or any
of the 92 partition types fdisk knows about), and end up with a situation
where the type of filesystem in a partition doesn't match what the partition
table says it should have.

Partitioning and formatting are separate operations, even under DOS, so it
would be unwise to blindly assume that what the partition table says is
correct.

_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/ Top-posting!
\_^_/ rm -rf /bin/laden >What's the most annoying thing on Usenet?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Linux)

iD8DBQFAY3pyVgTKos01OwkRAjsMAJ9x84UjmLQwX+mc5v9X131Iek7awQCgug5N
EkurMT9ekWxriGTK0OYQYUw=
=+wL3
-----END PGP SIGNATURE-----

"DIY DataRecovery" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
> "Folkert Rienstra" <see_reply-(E-Mail Removed)> wrote in message
> > > >
> > > > That still doesn't explain the conflicting info.
> > > > It would then be a NTFS partition and not a Fat32 partition.
>
> - Situation: FAT32 drive, all's well.
>
> - Accident: FAT32 drive is formatted NTFS
>
> - Problem: File system is now NTFS according to partition table

And in actual fact.

> HOWEVER the file system more interesting for analysis is FAT32;
> iRecover should treat this as a FAT32 drive rather than an NTFS one.

But since it now is a valid NTFS partition it should at least mention that.

>
> The conflicting info is, that while the partition table says NTFS, we're not
> interested in NTFS data structures, we're interested IN FAT data structures.

Apparently that was not clear to OP. Perhaps that should be made clearer.

>
> --
> Joep

"Scott Alfter" <(E-Mail Removed)> wrote in message news:lUK8c.3522$GH3.2316@fed1read07
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In article c3tb0b$20ar2t$(E-Mail Removed), Folkert Rienstra top-posted (grr):

Which I consider a minute offense compared to posting
someone's <reply address> instead of the <sender address>.

(huge grr)

> > "Joep" <j o e p @ d i y d a t a r e c o v e r y . n l> top-posted (grr) in message news:(E-Mail Removed)
> >
> > > In the partition table it would say NTFS, however the file system you want
> > > to recover from would be FAT32. As iRecover scan the partition it will find
> > > more and more evidence that the data actually present corresponds with a FAT
> > > type partition (assuming the partition was formatted in error and no data
> > > was written to it yet).
> >
> > So how does the FATxx designation get itself in the partition table,
> > if not by the formatting operation?

I retract the question because -after reread- it didn't make any sense.
Apparently I misinterpreted Joep's answer.

[snip]

Dear Friend,

You can use Kernel for Window data recovery software to recover your lost data from your corrupted hard disk and you can download this software from here
http://www.recoverlostpartition.com