One basic rule when dealing with “hibernated” volumes is to never write anything to them from another operating system. Otherwise, when a hibernated operating system is resumed, there will be a difference between what is on a drive and what the operating system considers to be on that drive.
In Linux, the NTFS-3G driver is issuing the following error message when trying to mount a “hibernated” volume in the read-write mode:
Windows is hibernated, refused to mount. The disk contains an unclean file system (0, 0). Metadata kept in Windows cache, refused to mount. Falling back to read-only mount because the NTFS partition is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting.)
But this rule isn’t enforced in the Windows world. An NTFS volume is automatically mounted in the read-write mode even if it belongs to a hibernated operating system.
Since the fast startup mode, which uses the hibernation feature to restore the state of the kernel and the loaded drivers, is enabled by default in Windows 8.1 & 10 installations running on most modern computers, such behavior can lead to data corruption in a dual-boot configuration or when a system drive is attached to another computer.
From a forensics perspective, this means that hibernation files may contain some important data.
