Skip to content

Conversation

@benjarobin
Copy link

I am sharing these 2 commits:

  • In my personal use case, I only mount as read-only the bitlocker volume, and I wanted to be sure that there will not have any modification to the volume. So open the disk device as requested by command line arguments
  • After shrinking the bitlocker volume using "Disk Management" Windows 10 version 1909, the encrypted_volume_size metadata field is not updated, so do not trust it... Use instead the partition size.

@haobinnan
Copy link
Contributor

It is not recommended to merge regarding the modification of encrypted_volume_size, as the value will not be updated when shrinking Bitlocker. That does not have any effect. If the Bitlocker is extended, the value will be updated automatically.
In addition, it is not recommedended to use ioctl. If it is an image file, then it is meaningless to use ioctl.

@superbonaci
Copy link
Contributor

superbonaci commented Sep 7, 2025

I am sharing these 2 commits:

  • In my personal use case, I only mount as read-only the bitlocker volume, and I wanted to be sure that there will not have any modification to the volume. So open the disk device as requested by command line arguments

You have to use the read-only flags for that, both when unlocking the encrypted volume file (dislocker-file is created) and when mounting the dislocker-file as ntfs volume. This should be enough.

you can set as read-only the device or partition itself:

sudo blockdev --setro /dev/sda1

For hardware level:

sudo hdparm -r1 /dev/sda1
  • After shrinking the bitlocker volume using "Disk Management" Windows 10 version 1909, the encrypted_volume_size metadata field is not updated, so do not trust it... Use instead the partition size.

I don't understand what you mean. You mean resizing the volume with Windows while it's mounted or after that? Can you provide example before and after the resizing so we can see real values? Maybe it's been already fixed in a more recent commit @benjarobin

@superbonaci
Copy link
Contributor

@haobinnan do you recommend to close this PR?

@haobinnan
Copy link
Contributor

@haobinnan do you recommend to close this PR?

yes

@benjarobin
Copy link
Author

I no longer needs this modification since I am no longer using a Windows with bitlocker.

But to explain again my issue:

  • From Windows you could resize a partition, even the active one, from "Disk Management" utility.
  • Sadly if the partition is encrypted using bitlocker, when the partition is resized (using the Windows "Disk Management" utility), the filesystem is resized, but the bitlocker metadata are not updated to reflect the new partition size.

So the proposal was to ignore the size in the bitlocker metadata, and only rely on the partition size.

@superbonaci
Copy link
Contributor

superbonaci commented Sep 8, 2025

@benjarobin I think that happens also with the partition label of a Bitlocker volume. If you rename a Bitlocker drive in Windows, the new label will be displayed in My Computer but the old label will remain also in the metadata forever. I don't know if you ever realized but I think there can be other fields duplicated. Likely those fields can't be renamed without decrypting and encrypting again the volume.

I'll try to reproduce the issue of the partition size and label. If dislocker shows the size and label of the bitlocker as values that don't match the current values but those are the values stored in the metadata, it's a correct implementation. You have to use other system tools to get the values for the unlocked volume or partition, that are the real ones.

This is what looks like to me I may be wrong.

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

Successfully merging this pull request may close these issues.

3 participants