# Why didn't ReadDirectoryChangesW provide a way to correlate the two sides of a rename operation?

DevFeed: [Why didn't ReadDirectoryChangesW provide a way to correlate the two sides of a rename operation?](<https://devfeed.tech/articles/why-didn-t-read-directory-changesw-provide-a-way-to-correlate-the-two-sides-of-a-rename-operation-21762.md>)

Original publisher: [Read original article](<https://devblogs.microsoft.com/oldnewthing/20260914-00/?p=112696>)

Author: Raymond Chen

Published: 2026-09-14T14:00:00Z

Content type: article

Language: en

Sources: [Raymond Chen](<https://devfeed.tech/sources/raymond-chen.md>)

Topics: [Filesystems](<https://devfeed.tech/topics/filesystems.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [concurrent](<https://devfeed.tech/tags/concurrent.md>), [events](<https://devfeed.tech/tags/events.md>), [files](<https://devfeed.tech/tags/files.md>), [ids](<https://devfeed.tech/tags/ids.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [information](<https://devfeed.tech/tags/information.md>), [old-new-thing](<https://devfeed.tech/tags/old-new-thing.md>), [other](<https://devfeed.tech/tags/other.md>), [post](<https://devfeed.tech/tags/post.md>), [systems](<https://devfeed.tech/tags/systems.md>)

## AI overview

The article explains why ReadDirectoryChangesW did not explicitly provide a mechanism for correlating the two events generated by a file rename. It suggests that the events were expected to occur consecutively, but that assumption was never documented and could fail when concurrent renames or disk activity interleave events. File IDs provide the information needed to correlate the two sides reliably.

## Source excerpt

Perhaps it wasn't necessary, or perhaps it didn't occur to them that this a problem. The post Why didn't <CODE>ReadDirectoryChangesW</CODE> provide a way to correlate the two sides of a rename operation? appeared first on The Old New Thing.