rmdir fails because iterator is not released

[tizbac]

Sorry for not following bug report model but the issue is also reported on nextcloud and fixed

https://help.nextcloud.com/t/unable-to-delete-directories-text-file-busy/86468/3

Adding unset($it); as they say on forum post fixes it

[iasdeoupxe]

Forum posts is probably talking about this: nextcloud/server#46027

[tizbac]

Correct Il sab 22 mar 2025, 13:03 iasdeoupxe ***@***.***> ha scritto:

…

Probably talking about this: nextcloud/server#46027 <nextcloud/server#46027> — Reply to this email directly, view it on GitHub <#41361 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABBV6XUJFDJTMYJVBE3LZD2VVGQ3AVCNFSM6AAAAABZPQPEQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBVGIZTQMBVHE> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: iasdeoupxe]*iasdeoupxe* left a comment (owncloud/core#41361) <#41361 (comment)> Probably talking about this: nextcloud/server#46027 <nextcloud/server#46027> — Reply to this email directly, view it on GitHub <#41361 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABBV6XUJFDJTMYJVBE3LZD2VVGQ3AVCNFSM6AAAAABZPQPEQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBVGIZTQMBVHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[iasdeoupxe]

Looking still relevant.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[iasdeoupxe]

Looking still relevant.

[DeepDiver1975]

🤖 Automated issue triage by Claude Code review agent.

Confirmed — this is a real bug, and the located cause matches the forum/Nextcloud report.

Root cause

In lib/private/Files/Storage/Local.php the rmdir() method builds a recursive iterator over the directory and then, after draining it, immediately removes the directory itself — but the iterator object $it is still alive and holding an open handle to that directory at the time of the final rmdir():

public function rmdir($path) {
    ...
    $it = new \RecursiveIteratorIterator(
        new \RecursiveDirectoryIterator($this->getSourcePath($path)),
        \RecursiveIteratorIterator::CHILD_FIRST
    );
    $it->rewind();
    while ($it->valid()) {
        ...
        $it->next();
    }
    return \rmdir($this->getSourcePath($path));   // <-- $it still open here
}

Because the RecursiveDirectoryIterator keeps an open directory handle in scope, some storage backends (VirtualBox shared folders, certain NFS/CIFS mounts, Windows) treat the directory as "in use" and the final \rmdir() fails — often with a Text file busy warning. The directory handle is only freed when $it goes out of scope at function return, which is after the rmdir() call.

Fix

Release the iterator before removing the directory, e.g. add unset($it); (or $it = null;) immediately before the final return \rmdir($this->getSourcePath($path));. This mirrors the upstream Nextcloud fix in nextcloud/server#46027 referenced above ("release possible directory lock prior to removing directory"), and the unset($it); workaround reported on the linked forum thread.

Notes

• Affected line is the final \rmdir($this->getSourcePath($path)); in Local::rmdir() (around line 111 on master).
• The same pattern should be checked anywhere else a live RecursiveDirectoryIterator/opendir handle precedes a rmdir on the same path.

This issue is valid and still relevant on current code. (Automated fix generation is disabled for this repository, so this is a triage analysis only.)

[dj4oC]

Implementation prompt

Problem: In OC\Files\Storage\Local::rmdir(), the RecursiveDirectoryIterator/RecursiveIteratorIterator ($it) is still in scope holding an open directory handle when the final \rmdir($this->getSourcePath($path)) runs, so on some backends (NFS/CIFS, VirtualBox shared folders, Windows) the directory is reported busy and removal fails.

Acceptance criteria:

• After draining the iterator, the directory handle held by $it is released before the final \rmdir() call on the target path.
• Local::rmdir() successfully removes a non-empty directory tree, and returns true, on a filesystem where a still-open iterator handle would otherwise block removal (regression test simulating/asserting the handle is released prior to the final \rmdir).
• Existing recursive-delete behavior (files, symlinks, nested dirs, ./.. skipping) is unchanged.
• The \UnexpectedValueException catch path still returns false.

Files:

• lib/private/Files/Storage/Local.php — in rmdir(), release the iterator (unset($it); or $it = null;) immediately before return \rmdir($this->getSourcePath($path));. Mirrors the upstream Nextcloud fix (Fix rmdir() to release possible directory lock prior to removing directory nextcloud/server#46027) and the forum workaround referenced in this issue.

Constraints:

• Test coverage >= 85% on touched code (e2e preferred — run the tool, do not trust claimed %)
• Commit signing: GPG signature + DCO Signed-off-by
• Rebase onto base branch before pushing any auto-fix commit
• No root-directory edits

🤖 Automated by Claude Code

---

Generated by Claude Code