Is there a way to prevent Windows from touching another NTFS partition mounted by another OS?

[UCyborg]

Besides shutting the other OS down, because if it contains Windows, it can only be unmounted with full shutdown. I looked at the list of known partition IDs provided by fdisk (not the ancient DOS fdisk, but the one you typically get with Linux distros), one of them is 0x3F 0x3C, which is/was supposedly used by PartitionMagic software to prevent Windows from touching the partition while it's being modified.

However, Windows 7 and later apparently do something with the other partition, regardless if its ID is 0x3F 0x3C or whatever other unrecognized ID or even the special ID marking it as hidden. So if I hibernate Windows instance on partition 1, change partition 1's ID from Linux, boot the Windows instance on partition 2, that actually has automounting disabled, then reboot to Linux, restore partition 1's original ID and reboot to Windows instance on partition 1, that instance will notice something funny on its NTFS file system and want a reboot to run chkdsk.

Windows XP seems to leave the partition alone, if it has either an unrecognized ID or special ID marking it as hidden, but newer Windows versions are menaces in that regard. So maybe I should change something else to make the partition unrecognizable, perhaps changing its magic number "NTFS    " to something else. Thoughts?

Edited December 12, 2020 by UCyborg
0x3F -> 0x3C

[jaclaz]

Actually AFAIK the "temporary" partition ID used by Partition Magic was 0x3C:

https://www.win.tue.nl/~aeb/partitions/partition_types-1.html

But no idea if it changes anything.

The issue you describe (as a side note it would be interesting to know WHY you do that procedure) seems to me  more like an issue with a drive letter/device GUID that is "sticky" in the Regitry.

I mean a GUID (and a drive letter) is assigned by having a Disk Signature + an offset to the volume, there is no direct reference to partition ID.

If a given volume has been (once) mounted in the second (on second partition) intance of windows it will have two entries in the Registry in Dosdevices (not connected to partition ID), it is possible that Windows tries to access the volume nonetheless and does something triggering the need to run CHKDSK.

"NTFS" is not a "magic number", it is the filesytem ID in the bootsector.

The last two bytes (in the MBR and as well in the bootsector) 55AA are the "magic numbers".

Replacing them in the MBR (with - say - 0000) will make the whole disk "need to be initialized".

No idea if replacing them in the bootsector/VBR will do anything, in theory it should make the volume "not formatted", but it has to be tried.

Personally I would rather make a backup of the bootsector (only the first sector) then 00 it all (and later restore the backup).

jaclaz

 

[D.Draker]

7 hours ago, UCyborg said:

However, Windows 7 and later apparently do something with the other partition, regardless if its ID is 0x3F or whatever ...

Yes , you're right , I confirm it touches it 100% , and it also creates "MS reserved" partitons on my other HDDs as well. I just hate Windows 7 and later. I'd be glad to know how to prevent creating of "MS reserved" partitons in the future.

Windows Vista RTM (without SP) seems to leave the partition alone too , like XP , in my experience .

Edited December 12, 2020 by D.Draker
added note

[UCyborg]

10 hours ago, jaclaz said:

Actually AFAIK the "temporary" partition ID used by Partition Magic was 0x3C:

https://www.win.tue.nl/~aeb/partitions/partition_types-1.html

You're right, I didn't have the list opened so was going from my memory...

10 hours ago, jaclaz said:

If a given volume has been (once) mounted in the second (on second partition) intance of windows it will have two entries in the Registry in Dosdevices (not connected to partition ID), it is possible that Windows tries to access the volume nonetheless and does something triggering the need to run CHKDSK.

It was definitely mounted in the past. I forgot to mention, if I have already booted Windows on partition 1, before I hibernate it to boot OS on partition 2, I have to give that partition a drive letter (let's assign a letter H) then run the following:

mountvol H: /P

Otherwise the OS on partition 2 will be upset. Has to be done once per clean boot of OS on partition 1. It's like the action done by mountvol doesn't persist across reboots. I'll have to check what mountvol reports for partition without drive letters that I have run the previous command on after reboot, right after the running the command it says: *** NOT MOUNTABLE UNTIL A VOLUME MOUNT POINT IS CREATED ***

10 hours ago, jaclaz said:

as a side note it would be interesting to know WHY you do that procedure

I figured I can do that to save session in one OS, then I can go try something in another OS and then be back right back where I left. And since this doesn't reset uptime timer and everything else to reload from scratch, it doesn't disrupt seeing how the OS fares with longer periods without rebooting. But when two Win NT 6.x+ OSes are involved, this little problem occurs.

10 hours ago, jaclaz said:

Personally I would rather make a backup of the bootsector (only the first sector) then 00 it all (and later restore the backup).

So first 512 bytes of partition I want to hide (I've verified that sectors are 512 bytes on my disk)?

[jaclaz]

Yep, first 512 bytes or first sector.

The general idea is the following (even if for a number of reasons this actual message has not been clear).

What we call "Partition ID's" are actually "Protective Partition ID's", not different from the concept of the 0xEE "Protective ID" used on GPT disks to avoid MBR-only enabled OS to access them.

So what the 0x3C was intended to do was "let's mark this partition with a number that the OS knows nothing about".

And I don't think that 7 has changed anything in the mechanism.

In a nutshell DOS up to 6.22 recognized only ID's 0x1, 0x4, 0x5. 0x06

NT 4.00 only the 0x07 in addition to the above

DOS 7,x/8.x and Win9x/ME added to them the 0x0b,0x0c,0x0e,0xf

From 2K all of the above.

More recently, when exFAT came out, its ID is still 0x07, definitely making clear that 0x07 does not mean "NTFS", but rather "DOS! Here be lions!".

There is another ID (actually a non-ID) that you can try using which is 0x00.

0x00 essentially means for Windows "there is no partition entry in this slot" (but Linux can usually mount the partition in the slot just fine, this trick/quirk is used with grub4dos to directly map ISO images in the MBR).

But if the issue revolves around something that uses not the MBR but *some other* mechanism/setting that is "sticky" the change to only the MBR partition ID will be ineffective .

If you completely blank the first sector of a volume, on the other hand, for all Windows knows you are in the same situation as when you create a volume/partition in Disk Manager, you first create a partition and later you are asked to format it, if you choose to not format it, the partition/volume exists, it is defined in the MBR (and it is normally assigned a drive letter but its properties will show it as RAW and if you try to acces it you will be asked to format it).

Now, what is "enough" to have it "recognized as RAW" (i.e. not-recognized) is another thing, the "magic bytes" are irrelevant, and as well the "NTFS    " filesystem description, I believe the need is to blank the pointer to the $MFT, but at the end of the day it is easier/faster/better to just blank the whole sector.

If you blank with 00's the whole first sector is surely enough and it is (relatively) safe as in NTFS there is a backup copy of that sector, last sector of the partition (outside the volume but inside the partition), so you can do everything with a couple dd commands (in Linux) or similar, the bootsector is generally "locked" on a booted windows NT system[1] so you need a suitable tool or a workaround, see also this:

http://reboot.pro/topic/8200-grubinstexe-write-failed-vista-ntfs-bootsector/

Unfortunately I think that in your case you cannot use LockDismount (just in case):

http://reboot.pro/topic/12413-lockdismount-v0300-update/

as it operates at \\.\PhysicalDrive (i.e. whole disk) level.

jaclaz

 

[1] meaning the stupid post-XP ones

 

 

 

Edited December 13, 2020 by jaclaz
Corrected typos, added note.

[UCyborg]

Thanks, I'll give the "backup the first sector and zero it" approach a spin. I can use dd from Linux for the task, I'm quite familiar with it. And I was going to make it complicated by looking at what bytes to change in the first sector.

[jaclaz]

Ok, in the meantime I did a few checks (in XP).

You were right.

The "magic bytes" (55AA at the end) are irrelevant.
As well the "jump bytes" (EB5290 at the beginning) are irrelevant.

What is relevant is the "OEM string" ("NTFS     ", i.e. NTFS followed by 4 spaces or 4 hex 20 bytes).

Simply making the first letter small case, i.e. nTFS instead of NTFS, is enough to make the volume/partition RAW (but you need to unassign and re-assign the drive letter to have the OS "sense" the change).

Viceversa, i.e. while having a volume seen as RAW because of the "nTFS", the moment you write the capital N, the change is immediately sensed by the OS.

7 may behave differently, though.

jaclaz

[UCyborg]

On 12/13/2020 at 11:09 AM, jaclaz said:

There is another ID (actually a non-ID) that you can try using which is 0x00.

0x00 essentially means for Windows "there is no partition entry in this slot"

This works!

[jaclaz]

8 hours ago, UCyborg said:

This works!

Good.

You need to be anyway careful when (if) you need to use partitioning software or similar, as the 0x00 to any of them will likely look like an empty partition slot and thus "free" and usable, with the risk of  overwriting the address data.

jaclaz