Jonas L

Inside a guestos you are presented a virtual filesystem through the virtual drive driver. Its built by: Unpacking: \Windows\Containers\WindowsDefenderApplicationGuard.wim to \ProgramData\Microsoft\Windows\Containers\BaseImages\2530545b-7638-4eb6-a60c-10c33c8f41ce\BaseLayer\Files

I am guessing at these files are needed for stuff like file locking( oplocks ), many of the files are just hard links to the same files on hyper-v harddrive. When opened without write access you basicly get a direct mapping to the same data from inside the guest os.

Some files are specific for the sandbox, like customisation so windows update do not work. Those files are stored in vhd files that is layered upon the real directory when presented inside the vm.

When you open a file for write access the file gets duplicated to a ram drive(C:\Windows\System32\drivers\ramdisk.sys) (This is windows sandbox specific) That way it appears as you can change any file, but disk space is saved untill you you change them.

The ram drive for changed files is referred to as the scratch space/layer. To track files between different layers wcifs reparse points are used to give files unique identifiers.

But what if a file already have a reparse point that should be presented inside the guest os? Is the reparse point maybe instead being stored as extended attributes?