If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Lost Partition
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 |
#2
|
|||
|
|||
Lost Partition
Daniel wrote:
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/englis...s/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 |
#3
|
|||
|
|||
Lost Partition
"Paul" wrote in message ... Daniel wrote: 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/englis...s/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 |
#4
|
|||
|
|||
Lost Partition
Daniel wrote:
"Paul" wrote in message ... Daniel wrote: 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/englis...s/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 |
#5
|
|||
|
|||
Lost Partition
"Daniel" wrote:
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 |
#6
|
|||
|
|||
Lost Partition
Daniel wrote:
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 |
#7
|
|||
|
|||
Lost Partition
Paul wrote:
Daniel wrote: 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 OK, I did a test case here. And TestDisk did a good job. http://img846.imageshack.us/img846/9...zemismatch.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 |
#8
|
|||
|
|||
Lost Partition
Paul wrote:
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 |
#9
|
|||
|
|||
Lost Partition
"Paul" wrote in message ... Daniel wrote: 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 |
#10
|
|||
|
|||
Lost Partition
"Paul" wrote in message ... Paul wrote: 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 |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Lost Partition/Data - Recovery? Partition? Filenames? | dave | Storage (alternative) | 1 | February 7th 05 05:37 PM |
partition table lost after partition magic resize | ..tato.. | Storage (alternative) | 3 | June 24th 04 01:49 PM |
Lost a partition after using Partition Magic | WH Brave | Storage (alternative) | 4 | June 15th 04 05:27 PM |
About: Lost Partition | owlbird | Storage (alternative) | 0 | November 15th 03 05:55 PM |
Lost Partition | Moir | Storage (alternative) | 3 | October 2nd 03 01:07 AM |