Skip to content

[UDFS] Fix access denied when SetRenameInformationFile is called on a directory/file#344

Draft
Copilot wants to merge 5 commits into
udf-devfrom
copilot/udfs-fix-access-denied-result
Draft

[UDFS] Fix access denied when SetRenameInformationFile is called on a directory/file#344
Copilot wants to merge 5 commits into
udf-devfrom
copilot/udfs-fix-access-denied-result

Conversation

Copy link
Copy Markdown

Copilot AI commented May 1, 2026

Windows Explorer deletes items by moving them to the Recycle Bin via SetRenameInformation, while cmd.exe rd uses SetDispositionInformation. Two overly-strict guards in UDFSetRenameInfo were returning STATUS_ACCESS_DENIED on the rename path, surfacing in Explorer as "You need permission from Everyone to make changes to this folder."

Removed: Fcb->FcbCleanup > 1 guard

Rejected rename whenever more than one handle was open — e.g. Explorer browsing the directory on one handle while opening a second for the rename. Share-access violations are already enforced by IoCheckShareAccess in UDFCheckAccessRights.

Removed: UDFCheckDirOpenHandles and its call

Rejected rename of any directory whose subtree contained files with FcbCleanup != 0 — e.g. Explorer had opened files inside for thumbnail/metadata generation. UDF addresses files by physical ICB location; renaming a directory only changes the parent's FileIdentifier entry and cannot invalidate open handles to files inside. NTFS permits the same operation without restriction.

// Removed from UDFSetRenameInfo:

if (Fcb->FcbCleanup > 1) {
    try_return (RC = STATUS_ACCESS_DENIED);        // blocked multi-handle rename
}

if ((Fcb->FcbState & UDF_FCB_DIRECTORY) &&
    !UDFCheckDirOpenHandles(Fcb)) {
    try_return (RC = STATUS_ACCESS_DENIED);        // blocked dirs with open children
}

UDFCheckDirOpenHandles had no other callers and has been removed entirely along with its protos.h declaration.

…directory/file

Windows Explorer moves items to the Recycle Bin via SetRenameInformation, while
cmd.exe uses SetDispositionInformation directly. Two overly-strict guards in
UDFSetRenameInfo were blocking the rename path:

1. Fcb->FcbCleanup > 1 — rejected rename when more than one handle was open
   (e.g. Explorer had the directory open for browsing on one handle and opened
   a second handle for the rename).  Sharing violations are already enforced by
   IoCheckShareAccess inside UDFCheckAccessRights, so this extra check was
   redundant and incorrect.

2. UDFCheckDirOpenHandles — rejected rename of any directory whose subtree
   contained files with FcbCleanup != 0 (e.g. Explorer opened files inside for
   thumbnail or metadata generation).  UDF addresses files by physical ICB
   location, so moving a directory only changes the parent FileIdentifier entry
   and cannot invalidate open handles to files inside.  NTFS allows the same.

Remove both checks and the now-unused UDFCheckDirOpenHandles helper function.

Agent-Logs-Url: https://github.com/Zero3K20/reactos/sessions/4133b9c9-c6da-4d1e-9c9f-8b862376aa62

Co-authored-by: Zero3K20 <258969903+Zero3K20@users.noreply.github.com>
Copilot AI changed the title [WIP] Fix access denied result for SetRenameInformationFile [UDFS] Fix access denied when SetRenameInformationFile is called on a directory/file May 1, 2026
Copilot AI requested a review from Zero3K20 May 1, 2026 21:34
Copilot AI added a commit that referenced this pull request May 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[UDFS] Fix access denied result when SetRenameInformationFile is called on a directory/file

3 participants