While installing Linux recently, I found that Windows 10 would only
shrink the NTFS partition to approximately half of its previous size. I
read claims via a web search for information on this subject that there
are metadata in the middle of an NTFS partition, and Microsoft's tools
won't reduce the size of the file system beyond this point. I'm not sure
how accurate this is, although it's consistent with the observed results.
On 1/31/19 6:46 PM, Nic Baxter via luv-main wrote:
Thanks for the info guys.
My initial thought was why doesn't the partition tell the file system
to move the data. But thinking about it more, the partition doesn't
understand files and the file-system doesn't understand raw data.
I imagine you could add the functions but it would be a duplication
and a potential security hazard. Simpler and safer to move everything
to another disk and repartition.
Cheers
Nic
On 31/1/19 8:52 pm, Paul van den Bergen via luv-main wrote:
yep, pretty much what I was trying to say - on a mobile - while
distracted...
The FS has an index of some sort that keeps track of where the bits
are, etc. If you move the goal posts you have to change the index to
suit, otherwise 1) the OS doesn't know where to find the index and 2)
the index doesn't know where to find the files.
so in theory you could change the partition start and end point, as
long as they still encompass any "data", more the metadata where it
needs to be (most FS's expect the index and other metadata to be at a
specific place... well - ok. I'm going to hazzard all) and adjust
said metadata to know where the data actually is - and presuming it's
OK with now having it's written data somewhere in the middle of it's
"file system", it'll be fine...
does anyone do this? Bueller?
In the case of VM's, the underlying file system could have excellent
snapshot (copy on write) at the file system level but the hypervisor
doesn't have this exposed to it so it makes a new file instead and
writes all changes into that... which has consequences...
there are good reasons to not ask the file system to look too deeply
into the pdisk management, nor the VM to look at the file system that
it's busy abstracting away - but I still think it's a bloody waste of
an opportunity...
YMMV...
On Thu, 31 Jan 2019 at 19:32, Morrie Wyatt via luv-main
<[email protected] <mailto:[email protected]>> wrote:
Hi Nic.
A bit of googling found me at the following link:
http://www.file-recovery.com/recovery-understanding-file-system-ntfs.htm
Long and short of it is that the NTFS partition layout wants certain
components to be at defined offsets from the beginning of the
partition.
So in moving the partition by 200MB, it need to keep the
partition contents
in exactly the order in which it found them. Otherwise Windows is
likely
to chuck a major hissy fit and tell you that the partition is
corrupted or
missing.
A bit like a library shelf. If you want to add books at the left end,
you need to start by moving all the other books to the right,
starting
at the right hand end. You just can't move "A to C" to the end of "Z"
end without getting the entire alphabet out of sequence.
(Your librarian would quickly relieve you of a few choice bits of
your
anatomy.)
A good analogy.
Well it seems like a reasonable analogy. :-)
Regards,
Morrrie.
-----Original Message-----
From: luv-main [mailto:[email protected]
<mailto:[email protected]>] On Behalf Of Nic Baxter via
luv-main
Sent: Thursday, 31 January 2019 12:16 PM
To: [email protected] <mailto:[email protected]>
Subject: moving partition
Hi All
I am moving a 1TB NTFS partition 200MB to the right using gparted
and of
course it is very slow. I don't understand why gparted is moving
all of
the data. Why not just move 200MB and add it to the end of the
partition? My googling only tells me how to do it but not why.
Cheers
Nic
_______________________________________________
luv-main mailing list
[email protected] <mailto:[email protected]>
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
_______________________________________________
luv-main mailing list
[email protected] <mailto:[email protected]>
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
--
Dr Paul van den Bergen
_______________________________________________
luv-main mailing list
[email protected]
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
_______________________________________________
luv-main mailing list
[email protected]
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
_______________________________________________
luv-main mailing list
[email protected]
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
