"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
