Why didn’t Read­Directory­ChangesW provide a way to correlate the two sides of a rename operation?

This article discusses the lack of a correlation mechanism in Read­Directory­ChangesW for rename operations, speculating on the reasons behind this design choice. It highlights the potential issues with file system behavior and the assumptions made in tracking rename events.

From the article

Brian Dellisanti asked why Read­Directory­ChangesW didn’t provide a way to correlate the two sides of a rename operation .

My guess is that the implementation always generated the two events one right after the other, so “obviously” the way you correlate them is to save the old name when you see the FILE_ ACTION_ RENAMED_ OLD_ NAME , and when the FILE_ ACTION_ RENAMED_ NEW_ NAME comes immediately after, you have your two sides.

But they never wrote down that the two events always occur in direct succession. Which meant that when new file systems came along, they might not honor the unwritten rule. If two files are being renamed at the same time, is it possible that the two sets of rename events end up interleaved? There was nothing written down to forbid it, so I guess it’s possible.

Share this resource