# Understand how ReFS keeps block-cloned files independent when they change

> What happens when an application writes into a region shared by ReFS block clones?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-070-understand-how-refs-keeps-block-cloned-files-independent-when-they-change/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-08T18:16:01+00:00
- Modified: 2026-09-08T18:20:22+00:00
- Last reviewed by DSE: 2026-09-08
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

What happens when an application writes into a region shared by ReFS block clones?

## Potentially affected

Use this review when evaluating an application that uses ReFS block cloning.

## DSE recommendation

Ask the application owner to distinguish a logical copy operation from an independently stored physical copy in the design record.

## Article

## Source facts

Block cloning lets an application request a copy of a byte range within one file or between files. ReFS implements the copy through metadata and reference counts, allowing file regions to share the same physical data. When a shared region is written, ReFS allocates a new region for that write. Microsoft describes this allocate-on-write behavior as preserving isolation between the files. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/refs/block-cloning).

## Applicability

Use this review when evaluating an application that uses ReFS block cloning. Confirm the supported filesystem and application requirements before relying on the mechanism. Identify which files and operations the application is expected to clone.

## DSE recommendation

Ask the application owner to distinguish a logical copy operation from an independently stored physical copy in the design record. Choose a test that clones representative content and then changes one of the resulting files. Record the expected contents of each file after the change. Keep recovery and backup decisions separately documented rather than deriving them from copy performance.

## Verification

Run the approved clone-and-modify test and compare both files with their expected contents. Record the application operation and filesystem context, together with relevant capacity or I/O observations. Investigate any mismatch before enabling the workflow for important data. Repeat the acceptance review if the application’s copy method or supported storage configuration changes.

## Official references

[Microsoft Learn: Block cloning on ReFS](https://learn.microsoft.com/en-us/windows-server/storage/refs/block-cloning). Source reviewed September 8, 2026.

## Primary reference

- Name: Block cloning on ReFS
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/windows-server/storage/refs/block-cloning
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Understand how ReFS keeps block-cloned files independent when they change,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-070-understand-how-refs-keeps-block-cloned-files-independent-when-they-change/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.