when you resize a partition with data, gparted will move the data inside the partition to fit the new size.

imagine you have a 100gb partition with 50gb occupied. now you want to shrink it to 80, if there is stuff in the last 20gb, gparted will move them to available space in the first 80gb, and then make the partition.

still i definitely will not trust it and have backups

If you had a book which had on its Contents page:

Chapter 1 . . . . . . . . . . page 1

and you crossed it out, then wrote:

Chapter 1 . . . . . . . . . . page 1

Chapter 2 . . . . . . . . . . page 50

someone looking for Chapter 1 is still going to find all the text in the right place (as long as it was less than 50 pages).

Changing the partitition table is like changing the Contents page; it doesn't mess with the rest of the data. And if the new table points to the same place it did before, the data can still be found.

That said, if the filesystem still thinks it's 1TB, you may end up with future problems unless you resize it to fit the reduced partition.

Well, hard to say that everything is not corrupted unless you verify each bit. What file system are you using?

Partitioning I believe (if you don't format anything) is just rewriting drive headers and creating a new header at some new point on the disk for the next partition.

Obviously we aren't in the days of sequential files, so files are spread physically over the disk with space in between. I'm not up with the exact specifics on whatever the latest windows FS is and how it works, or how EXT works at that level, but it would seem you partitioned it at a point after the data ended.

That, or you haven't corrupted the inodes/pointers, so it appears that all the files are there, until you try to actually access that place on the disk. If the files existed in the space that the new partition is, then you're going to get errors. I suspect this is more likely, because inodes will exist in the first sequential bytes on the disk, while the actual file location could be anywhere.

Correct me if I'm wrong on any of the details here.

Awesome question.

The operating system, or OS, really does not care about whether it is a hard drive or a solid state drive when moving around the partitions.

Say your hard drives are pools. One is filled with molasses, and the other has water. The partitions are like the ropes in the pool. Perhaps you have no ropes. Maybe you have three, but two are so close to the wall, and each other, that only a small amount of stuff could occupy those lanes.

That leaves you with one really large lane. That's your data partition.

Water or molasses, the ropes are the same.

Storage media doesn't make a difference here. You can partition a spinning drive, an SSD, NVRAM, phase change storage, hell even magnetic core if you have enough of it.

It also depends on how you did the partitioning. A full partitioning program like gparted will intelligently move and resize partitions. But even if you blindly rewrote a partition table, if you did something like take a 100gb partition, changed it to 50gb, and added a 50gb partition after it, as long as the filesystem has only used that first 50gb, nothing bad will happen. A partition table just says "partition starts here, ends here".

Just look at the output of fdisk:

Disk /dev/sda: 100 GiB, 107374182400 bytes, 209715200 sectors
Disk model: Virtual disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xaf179753

Device     Boot     Start       End   Sectors Size Id Type
/dev/sda1  *         2048 192944127 192942080  92G 83 Linux
/dev/sda2       192944128 209715199  16771072   8G  5 Extended
/dev/sda5       192946176 209715199  16769024   8G 82 Linux swap / Solaris

Maybe there's just wasn't any data written past the partition point yet?