Lost Partition

[Daniel]

Hi

I am running W7 x64 on an new Asus PC. with an i5 CPU and 8GB RAM.

I have a 2TB USB Connected hard drive with two partitions 1 x 600GB and 1 x
1.4GB (approx) . Using W7 Disk management, I tried to change the second
partition to
two partitions by decreasing the size, then using the new unallocated space
to create a new partition, but the unallocated space does not show up
in Disk manager nor in Windows Explorer. I now have two partitions, 1 x
600GB and 1 x 700GB approx.

Any idea what I can do to get back my missing space?

Thanks

Daniel

 

[Paul]

Hi

I am running W7 x64 on an new Asus PC. with an i5 CPU and 8GB RAM.

I have a 2TB USB Connected hard drive with two partitions 1 x 600GB and
1 x 1.4GB (approx) . Using W7 Disk management, I tried to change the
second partition to
two partitions by decreasing the size, then using the new unallocated
space to create a new partition, but the unallocated space does not show up
in Disk manager nor in Windows Explorer. I now have two partitions, 1 x
600GB and 1 x 700GB approx.

Any idea what I can do to get back my missing space?

Thanks

Daniel

This is a novel situation you've got yourself in.

And this is all guesswork on my part.

With both primary and logical (extended) partitions,
I don't think you can "lose space" as such. So if
a partition is *properly* resized, some "blank space"
should show up. That leads me to conclude (rightly or
wrongly), that the resize was improper, and screwed up.

A partition has a physical and a logical size, and they
aren't always the same. Typically, there is a trivial
difference, because perhaps the cluster size doesn't
divide evenly (nicely) into the total partition size.
Half a cluster is left over at the end perhaps. So
they're perhaps never perfectly proportioned. And,
this is not really a big deal. Chump change.

I've run into this in Linux, and specifically, while
doing small resizing projects. (The idea being, to achieve
some kind of alignment I was looking for.) The thing is,
a partition has two dimensions, like this.

Physical partition size, as recorded in MBR and partition table
<-------------------------------------------------------------->
+--------------------------------------------------------------+
| | This space cannot |
| <----- Logical size of file system ----->| be used... |
+------------------------------------------+-------------------+

If you change the logical size of a file system, like on a FAT32
change the number of clusters from 2000 to 1000, then a space opens
up at the end of the partition, but that space is still inside
the partition. Space is not available, until it sits *outside*
the partition. On a properly resized partition, where physical=logical,
your space shows up, like this.

Physical partition size...
<----------------------------------------- >
+------------------------------------------+ |
| | This space can |
| <----- Logical size of file system ----->| be used... |
+------------------------------------------+ |

Now, if the resize operation fails half-way, then you can end
up with the first picture. The file system will claim to be
"smaller", and yet the free space doesn't show up. You need to
look in two places, with two different utilities, to detect it.

So what you need to do now, is compare the Windows file system
size info, versus the LBA in sectors using PTEDIT32. You can
get PTEDIT32 here, and record the numbers shown for that drive.
Just unzip this, then run the .exe directly. No install needed.

ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip

Note - on Windows 7, you must "Run as Administrator" when using that
program. Otherwise, the program returns "error 5" if you forget.
Right-click the executable, and from the pop-up context menu select
Run As Administrator. The resulting PTEDIT32 numbers, look like this.

http://www.goodells.net/dellrestore/files/dell-tbl.gif

In that example, the physical size of the
second partition is 70894845 sectors.

When in file explorer in Windows, right click on the drive
letter (partition), and get size info from that. If there
is a substantial difference, compared to 70894845 sectors,
then you could have the problem in the first figure, where
the logical size of the partition is now much smaller, but
the step that adjusts the physical size has failed.

How do you fix it ? Good question. I could probably
do it from Linux, if I could remember the names of
the utilities.

See, this one only does the logical part, and doesn't
fix the MBR to reflect the correct physical size. So
this actually encourages the mess above

http://linux.die.net/man/8/ntfsresize

"To resize a filesystem on a partition, you must resize BOTH
the filesystem and the partition by editing the partition table
on the disk. Similarly to other command line filesystem resizers,
ntfsresize doesn't manipulate the size of the partitions, hence
to do that you must use a disk partitioning tool as well, for
example fdisk(8). Alternatively you could use one of the many user
friendly partitioners that uses ntfsresize internally, like
Mandriva's DiskDrake, QTParted, SUSE/Novell's YaST Partitioner,
IBM's EVMS, *GParted* or Debian/Ubuntu's Partman.

IMPORTANT! It's a good practice making REGULAR BACKUPS of
your valuable data, especially before using ANY partitioning tools."

So in that example, a Linux admin uses ntfsresize first, followed
by the command line tool fdisk, to bring both into line. For an
automated tool that does both for you, the GUI tool GParted
is the thing to use. You can learn a lot from GParted command
log, as to all the crazy things it does while making changes
to a partition.

If this was the situation you were in, then I could probably
fix it if I was sitting in front of the computer. I don't know
if any Windows utilities would notice the difference and fix it
for you. As most of the time, they ignore the trivial differences
that might be present and not say a word about them (the
"half a cluster" thing).

Just a theory,
Paul

 

[Daniel]

"Paul" wrote in message

Hi

I am running W7 x64 on an new Asus PC. with an i5 CPU and 8GB RAM.

I have a 2TB USB Connected hard drive with two partitions 1 x 600GB and 1
x 1.4GB (approx) . Using W7 Disk management, I tried to change the second
partition to
two partitions by decreasing the size, then using the new unallocated
space to create a new partition, but the unallocated space does not show
up
in Disk manager nor in Windows Explorer. I now have two partitions, 1 x
600GB and 1 x 700GB approx.

Any idea what I can do to get back my missing space?

Thanks

Daniel

This is a novel situation you've got yourself in.

And this is all guesswork on my part.

With both primary and logical (extended) partitions,
I don't think you can "lose space" as such. So if
a partition is *properly* resized, some "blank space"
should show up. That leads me to conclude (rightly or
wrongly), that the resize was improper, and screwed up.

A partition has a physical and a logical size, and they
aren't always the same. Typically, there is a trivial
difference, because perhaps the cluster size doesn't
divide evenly (nicely) into the total partition size.
Half a cluster is left over at the end perhaps. So
they're perhaps never perfectly proportioned. And,
this is not really a big deal. Chump change.

I've run into this in Linux, and specifically, while
doing small resizing projects. (The idea being, to achieve
some kind of alignment I was looking for.) The thing is,
a partition has two dimensions, like this.

Physical partition size, as recorded in MBR and partition table
<-------------------------------------------------------------->
+--------------------------------------------------------------+
| | This space cannot |
| <----- Logical size of file system ----->| be used... |
+------------------------------------------+-------------------+

If you change the logical size of a file system, like on a FAT32
change the number of clusters from 2000 to 1000, then a space opens
up at the end of the partition, but that space is still inside
the partition. Space is not available, until it sits *outside*
the partition. On a properly resized partition, where physical=logical,
your space shows up, like this.

Physical partition size...
<----------------------------------------- >
+------------------------------------------+ |
| | This space can |
| <----- Logical size of file system ----->| be used... |
+------------------------------------------+ |

Now, if the resize operation fails half-way, then you can end
up with the first picture. The file system will claim to be
"smaller", and yet the free space doesn't show up. You need to
look in two places, with two different utilities, to detect it.

So what you need to do now, is compare the Windows file system
size info, versus the LBA in sectors using PTEDIT32. You can
get PTEDIT32 here, and record the numbers shown for that drive.
Just unzip this, then run the .exe directly. No install needed.

ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip

Note - on Windows 7, you must "Run as Administrator" when using that
program. Otherwise, the program returns "error 5" if you forget.
Right-click the executable, and from the pop-up context menu select
Run As Administrator. The resulting PTEDIT32 numbers, look like this.

http://www.goodells.net/dellrestore/files/dell-tbl.gif

In that example, the physical size of the
second partition is 70894845 sectors.

When in file explorer in Windows, right click on the drive
letter (partition), and get size info from that. If there
is a substantial difference, compared to 70894845 sectors,
then you could have the problem in the first figure, where
the logical size of the partition is now much smaller, but
the step that adjusts the physical size has failed.

How do you fix it ? Good question. I could probably
do it from Linux, if I could remember the names of
the utilities.

See, this one only does the logical part, and doesn't
fix the MBR to reflect the correct physical size. So
this actually encourages the mess above

http://linux.die.net/man/8/ntfsresize

"To resize a filesystem on a partition, you must resize BOTH
the filesystem and the partition by editing the partition table
on the disk. Similarly to other command line filesystem resizers,
ntfsresize doesn't manipulate the size of the partitions, hence
to do that you must use a disk partitioning tool as well, for
example fdisk(8). Alternatively you could use one of the many user
friendly partitioners that uses ntfsresize internally, like
Mandriva's DiskDrake, QTParted, SUSE/Novell's YaST Partitioner,
IBM's EVMS, *GParted* or Debian/Ubuntu's Partman.

IMPORTANT! It's a good practice making REGULAR BACKUPS of
your valuable data, especially before using ANY partitioning tools."

So in that example, a Linux admin uses ntfsresize first, followed
by the command line tool fdisk, to bring both into line. For an
automated tool that does both for you, the GUI tool GParted
is the thing to use. You can learn a lot from GParted command
log, as to all the crazy things it does while making changes
to a partition.

If this was the situation you were in, then I could probably
fix it if I was sitting in front of the computer. I don't know
if any Windows utilities would notice the difference and fix it
for you. As most of the time, they ignore the trivial differences
that might be present and not say a word about them (the
"half a cluster" thing).

Just a theory,
Paul

Hi

thanks for your post

I ran PTEDIT32.EXE but it only found my Hard drive that contains the c:
drive and not the other two
USB attaches drives. Both were visible in Explorer.

Any idea what I am doing wrong?

Cheers

Daniel

 

[Paul]

"Paul" wrote in message

This is a novel situation you've got yourself in.

And this is all guesswork on my part.

With both primary and logical (extended) partitions,
I don't think you can "lose space" as such. So if
a partition is *properly* resized, some "blank space"
should show up. That leads me to conclude (rightly or
wrongly), that the resize was improper, and screwed up.

A partition has a physical and a logical size, and they
aren't always the same. Typically, there is a trivial
difference, because perhaps the cluster size doesn't
divide evenly (nicely) into the total partition size.
Half a cluster is left over at the end perhaps. So
they're perhaps never perfectly proportioned. And,
this is not really a big deal. Chump change.

I've run into this in Linux, and specifically, while
doing small resizing projects. (The idea being, to achieve
some kind of alignment I was looking for.) The thing is,
a partition has two dimensions, like this.

Physical partition size, as recorded in MBR and partition table
<-------------------------------------------------------------->
+--------------------------------------------------------------+
| | This space cannot |
| <----- Logical size of file system ----->| be used... |
+------------------------------------------+-------------------+

If you change the logical size of a file system, like on a FAT32
change the number of clusters from 2000 to 1000, then a space opens
up at the end of the partition, but that space is still inside
the partition. Space is not available, until it sits *outside*
the partition. On a properly resized partition, where physical=logical,
your space shows up, like this.

Physical partition size...
<----------------------------------------- >
+------------------------------------------+ |
| | This space can |
| <----- Logical size of file system ----->| be used... |
+------------------------------------------+ |

Now, if the resize operation fails half-way, then you can end
up with the first picture. The file system will claim to be
"smaller", and yet the free space doesn't show up. You need to
look in two places, with two different utilities, to detect it.

So what you need to do now, is compare the Windows file system
size info, versus the LBA in sectors using PTEDIT32. You can
get PTEDIT32 here, and record the numbers shown for that drive.
Just unzip this, then run the .exe directly. No install needed.

ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip


Note - on Windows 7, you must "Run as Administrator" when using that
program. Otherwise, the program returns "error 5" if you forget.
Right-click the executable, and from the pop-up context menu select
Run As Administrator. The resulting PTEDIT32 numbers, look like this.

http://www.goodells.net/dellrestore/files/dell-tbl.gif

In that example, the physical size of the
second partition is 70894845 sectors.

When in file explorer in Windows, right click on the drive
letter (partition), and get size info from that. If there
is a substantial difference, compared to 70894845 sectors,
then you could have the problem in the first figure, where
the logical size of the partition is now much smaller, but
the step that adjusts the physical size has failed.

How do you fix it ? Good question. I could probably
do it from Linux, if I could remember the names of
the utilities.

See, this one only does the logical part, and doesn't
fix the MBR to reflect the correct physical size. So
this actually encourages the mess above

http://linux.die.net/man/8/ntfsresize

"To resize a filesystem on a partition, you must resize BOTH
the filesystem and the partition by editing the partition table
on the disk. Similarly to other command line filesystem resizers,
ntfsresize doesn't manipulate the size of the partitions, hence
to do that you must use a disk partitioning tool as well, for
example fdisk(8). Alternatively you could use one of the many user
friendly partitioners that uses ntfsresize internally, like
Mandriva's DiskDrake, QTParted, SUSE/Novell's YaST Partitioner,
IBM's EVMS, *GParted* or Debian/Ubuntu's Partman.

IMPORTANT! It's a good practice making REGULAR BACKUPS of
your valuable data, especially before using ANY partitioning tools."

So in that example, a Linux admin uses ntfsresize first, followed
by the command line tool fdisk, to bring both into line. For an
automated tool that does both for you, the GUI tool GParted
is the thing to use. You can learn a lot from GParted command
log, as to all the crazy things it does while making changes
to a partition.

If this was the situation you were in, then I could probably
fix it if I was sitting in front of the computer. I don't know
if any Windows utilities would notice the difference and fix it
for you. As most of the time, they ignore the trivial differences
that might be present and not say a word about them (the
"half a cluster" thing).

Just a theory,
Paul

Hi

thanks for your post

I ran PTEDIT32.EXE but it only found my Hard drive that contains the c:
drive and not the other two
USB attaches drives. Both were visible in Explorer.

Any idea what I am doing wrong?

Cheers

Daniel

I can view my USB hard drive with PTEDIT32 here.

Even if you prepared them GPT (GUID Partition Table), there
is still a "protective MBR" and that means each disk still
has an MBR on it. Even if it doesn't mean very much on a
GPT disk.

It should have worked.

Paul

 

[VanguardLH]

I am running W7 x64 on an new Asus PC. with an i5 CPU and 8GB RAM.

I have a 2TB USB Connected hard drive with two partitions 1 x 600GB and 1 x
1.4GB (approx) . Using W7 Disk management, I tried to change the second
partition to
two partitions by decreasing the size, then using the new unallocated space
to create a new partition, but the unallocated space does not show up
in Disk manager nor in Windows Explorer. I now have two partitions, 1 x
600GB and 1 x 700GB approx.

Rather than figure out what got screwed up or how, you might want to use
something that is a more robust partition manager than what Microsoft
gives its users, like:

Easeus' Partition Magic Home edition (free)
http://www.partition-tool.com/personal.htm

 

[Paul]

Hi

thanks for your post

I ran PTEDIT32.EXE but it only found my Hard drive that contains the c:
drive and not the other two
USB attaches drives. Both were visible in Explorer.

Any idea what I am doing wrong?

Cheers

Daniel

Another tool you can try, is TestDisk.

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

It should be able to scan and compute a new MBR, and
perhaps that will give you some idea of what is going on.
There is a Windows version. It has a text based interface.
*Don't* have it write a new MBR. You just want it
to gather details about the physical size of the partitions.
Then compare that info to the size info Windows is giving
you (the logical file system size).

I don't really know whether TestDisk is smart enough to
detect the difference between the physical and logical
size, and resize the physical so it just fits the
logical. If it did do that, then writing out the new MBR
might alleviate your situation. (Your free space would
come back.)

What I'd do, is back up the MBR first, before allowing
TestDisk to write it. That's in case I have to recover
it for some reason. You can do that with "dd".

http://www.chrysocome.net/dd

Do "dd --list" to get the names of the partitions.

Then, back up the MBR. The disk numbering should be the
same as seen in Disk Management.

dd if=\\?\Device\Harddisk1\Partition0 of=C:\stuff\myseconddiskmbr.bin bs=512 count=1

That creates a 512 byte file, with the MBR of the second disk stored
in it. My disks would be Harddisk0 and Harddisk1. Partition0 means
to start at the origin of the disk drive. The "if" and "of" are input
and output specifications. "bs" is block size. "count" is the number
of blocks to copy. Simply reverse the command, if putting it back later.
This would be useful, if later I didn't like what TestDisk
had done, and needed to recover things.

dd if=C:\stuff\myseconddiskmbr.bin of=\\?\Device\Harddisk1\Partition0 bs=512 count=1

Naturally, I hope the info on that disk is backed up somewhere.
Safety first...

HTH,
Paul

 

[Paul]

Another tool you can try, is TestDisk.

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

It should be able to scan and compute a new MBR, and
perhaps that will give you some idea of what is going on.
There is a Windows version. It has a text based interface.
*Don't* have it write a new MBR. You just want it
to gather details about the physical size of the partitions.
Then compare that info to the size info Windows is giving
you (the logical file system size).

I don't really know whether TestDisk is smart enough to
detect the difference between the physical and logical
size, and resize the physical so it just fits the
logical. If it did do that, then writing out the new MBR
might alleviate your situation. (Your free space would
come back.)

What I'd do, is back up the MBR first, before allowing
TestDisk to write it. That's in case I have to recover
it for some reason. You can do that with "dd".

http://www.chrysocome.net/dd

Do "dd --list" to get the names of the partitions.

Then, back up the MBR. The disk numbering should be the
same as seen in Disk Management.

dd if=\\?\Device\Harddisk1\Partition0 of=C:\stuff\myseconddiskmbr.bin
bs=512 count=1

That creates a 512 byte file, with the MBR of the second disk stored
in it. My disks would be Harddisk0 and Harddisk1. Partition0 means
to start at the origin of the disk drive. The "if" and "of" are input
and output specifications. "bs" is block size. "count" is the number
of blocks to copy. Simply reverse the command, if putting it back later.
This would be useful, if later I didn't like what TestDisk
had done, and needed to recover things.

dd if=C:\stuff\myseconddiskmbr.bin of=\\?\Device\Harddisk1\Partition0
bs=512 count=1

Naturally, I hope the info on that disk is backed up somewhere.
Safety first...

HTH,
Paul

OK, I did a test case here. And TestDisk did a good job.

http://img846.imageshack.us/img846/9052/sizemismatch.gif

I took a 250GB hard drive, and created a 250GB NTFS partition.
Disk Management would then show a single partition, stretching
across the entire disk.

In Linux, I resized the partition.

sudo ntfsresize -n 100G /dev/sdc1

and that resizes the 250GB partition down to 100GB. That
changes the logical size of the partition, without correcting
the physical size.

In the Imageshack picture above, the upper two dialogs show the
physical (250GB) and logical (100GB pie chart) views of the disk.
Notice how 150GB of "space" has gone missing.

Then, I used a copy of TestDisk for Windows, to scan the disk and
recompute the partition table. TestDisk is smart enough to notice
the physical and logical don't match. In its proposed new MBR,
it changed the LBA size of the partition, closer to the 100GB size
it really should be.

The lower image, shows Disk Management after a reboot, using the
new MBR. The free space that should be there, is now apparent.

Now, this experiment was carefully controlled. In that, I actually
zeroed the whole disk before doing the experiment. That's to prevent
TestDisk from picking up bogus info from pre-existing partitions
that aren't really there any more. That's the downsize of TestDisk,
is that it can easily propose a new partition table, which doesn't
accurately reflect the real partitions the user is using at the moment.
For example, TestDisk can discover two partitions that overlap, and
not warn you. Which would be a recipe for disaster on the next reboot.

So if you do use TestDisk as I did in this example, review *carefully*
the results, to make sure there isn't an inadvertent error in the
proposed new value of MBR/partition table.

Paul

 

[Paul]

In Linux, I resized the partition.

sudo ntfsresize -n 100G /dev/sdc1

I think that should have been

sudo ntfsresize -s 100G /dev/sdc1

You add the -n option, when "previewing" the
command is going to run OK on the actual disk.

Paul

 

[Daniel]

"Paul" wrote in message

Hi

thanks for your post

I ran PTEDIT32.EXE but it only found my Hard drive that contains the c:
drive and not the other two
USB attaches drives. Both were visible in Explorer.

Any idea what I am doing wrong?

Cheers

Daniel

Another tool you can try, is TestDisk.

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

It should be able to scan and compute a new MBR, and
perhaps that will give you some idea of what is going on.
There is a Windows version. It has a text based interface.
*Don't* have it write a new MBR. You just want it
to gather details about the physical size of the partitions.
Then compare that info to the size info Windows is giving
you (the logical file system size).

I don't really know whether TestDisk is smart enough to
detect the difference between the physical and logical
size, and resize the physical so it just fits the
logical. If it did do that, then writing out the new MBR
might alleviate your situation. (Your free space would
come back.)

What I'd do, is back up the MBR first, before allowing
TestDisk to write it. That's in case I have to recover
it for some reason. You can do that with "dd".

http://www.chrysocome.net/dd

Do "dd --list" to get the names of the partitions.

Then, back up the MBR. The disk numbering should be the
same as seen in Disk Management.

dd if=\\?\Device\Harddisk1\Partition0 of=C:\stuff\myseconddiskmbr.bin
bs=512 count=1

That creates a 512 byte file, with the MBR of the second disk stored
in it. My disks would be Harddisk0 and Harddisk1. Partition0 means
to start at the origin of the disk drive. The "if" and "of" are input
and output specifications. "bs" is block size. "count" is the number
of blocks to copy. Simply reverse the command, if putting it back later.
This would be useful, if later I didn't like what TestDisk
had done, and needed to recover things.

dd if=C:\stuff\myseconddiskmbr.bin of=\\?\Device\Harddisk1\Partition0
bs=512 count=1

Naturally, I hope the info on that disk is backed up somewhere.
Safety first...

HTH,
Paul

Hi

all my data is backed up, or in this case I have the originals, the problem
drive being
the backup Drive.

I am extremely busy and will not get to fix this problem for a week or so,
thanks for your input, I will get back to you.

Regards

Daniel

 

[Daniel]

"Paul" wrote in message

In Linux, I resized the partition.

sudo ntfsresize -n 100G /dev/sdc1

I think that should have been

sudo ntfsresize -s 100G /dev/sdc1

You add the -n option, when "previewing" the
command is going to run OK on the actual disk.

Paul

Hi Paul

thank you for your extremely good advice, I have learned a lot and will
now have the tools if I get into this situation again, however because of
the limitations of time I tried Easeus Partition Master and it fixed the
problem
without the need for deciding what was happening.

Thanks again.

regards

Daniel

 

[Daniel]

"VanguardLH" wrote in message

I am running W7 x64 on an new Asus PC. with an i5 CPU and 8GB RAM.

I have a 2TB USB Connected hard drive with two partitions 1 x 600GB and 1
x
1.4GB (approx) . Using W7 Disk management, I tried to change the second
partition to
two partitions by decreasing the size, then using the new unallocated
space
to create a new partition, but the unallocated space does not show up
in Disk manager nor in Windows Explorer. I now have two partitions, 1 x
600GB and 1 x 700GB approx.

Rather than figure out what got screwed up or how, you might want to use
something that is a more robust partition manager than what Microsoft
gives its users, like:

Easeus' Partition Magic Home edition (free)
http://www.partition-tool.com/personal.htm

Hi

thanks for your advice, I used Easeus Partition Master free edition and
it took 3 minutes to fix the problem, I now have my whole Drive back.

Regards

Daniel

 

[clairexiang1]

hi, you may need to check your disk to see if there is bad sector in your disk. you can also defragment your disk.

AOMEI Partition Assistant(Home Edition)
http://www.extend-partition.com/free-partition-manager.html

 

[jiongs546647]

I don't think your description is right, your disk is 2TB, there should nothave such a problem, you can use this software: http://www.partition-magic..org/ to have a try, if you can post a screenshot of your disk management and post the picture's link here, that is better.