Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expansion issues #102

Open
Scarlet-Phonavis opened this issue Mar 28, 2024 · 2 comments
Open

Expansion issues #102

Scarlet-Phonavis opened this issue Mar 28, 2024 · 2 comments

Comments

@Scarlet-Phonavis
Copy link

Forewarning I do not have much tech knowledge regarding these things, I'm just listing some problems I've had that I don't see addressed on FAQ or here, so I'm not sure if something is just weird with my setup

Windows 10 Ver 2004 Build 19041.1415
This was all tested on a WD_BLACK SN770 2TB

Attempting to expand an encrypted volume, contrary to the FAQ, seems to cause pretty severe issues
I am using the windows diskmgmt.msc
The OS itself will acknowledge the partition being bigger, and Discrypter as well, but anything using the FileSytem API itself does not seem to.
IE, if I have a 1GB encrypted partition, then expand it another Gigabyte, after mounting Diskcrypter will report it as 2GB
But I can only stick 1GB of data inside it, and the properties menu only shows 1GB
This happens regardless if the volume is mounted or not upon expanding.
Upon decrypting the Disk, which will also waste disk writes on that 1GB expansion that was never touched, it'll still be 1GB, until it's expanded again by DiskMgmt.msc, then it will act properly.

Then it gets even weirder, if we have a 1GB encrypted partition, Partition A for simplicity, then an unrelated partition, Partition B, then expand partition A, windows will do what it's supposed to do and put that partition after Partition B
But, if we were to expand Partition A again, instead of merging into the Second partition A, we would get a third Partition A right next to the second one.
Amusingly these don't merge back together even after decrypting, so I have several of the same partition marked separately next to each other.
It is worth noting an expansion will be merged if its next to the initial encrypted partition, it's just the second and third that will refuse to merge while the first is encrypted. Though as mentioned before the expansion's space will be inaccessible.

Of course this can all just be avoided by decrypting and reencrypting, but that's not exactly SSD friendly

@Scarlet-Phonavis
Copy link
Author

Nvm about the strange behavior of Partition A's part 2 and 3 not merging, default windows behavior, cursed

Please I beg you though stop encrypting empty space

@RadarNyan
Copy link

The Windows built-in Disk Management has some weird undocumented behaviors. I suggest you avoid it and use the command-line utility DiskPart (also built-in) instead.

Also, I recommend you never use the "format" feature of DiskCryptor when creating a new encrypted volume. To save encryption time, you can first create a volume of your desired size, then shrink it, encrypt it, and finally extend it back. The reason for not creating the volume in a small size at the beginning is to avoid having NTFS MFT fragmentation in the future. Check my guide here #90 on how to do this with DiskPart: (Scroll down to the "Encrypt system partition before installing Windows" section)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants