Fix RegexpFs.Rename silently doing nothing for directories - #673
Open
januththedev wants to merge 1 commit into
Open
januththedev wants to merge 1 commit into
januththedev wants to merge 1 commit into
Conversation
januththedev
force-pushed
the
fix/regexpfs-rename-dir
branch
from
October 3, 2026 10:31
5842571 to
41ab900
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RegexpFs.Renamesilently does nothing when the source is a directoryDescription
The directory branch returns
nilinstead of delegating tor.source.Rename.Why that's wrong
RegexpFs's own doc comment states "The RegexpFs filters files (not directories) by regular expression." Directories are explicitly exempt from the filter:dirOrMatches,Open,Remove,RemoveAllandStatall treat a directory as automatically passing. SoRenamehas to delegate.Returning
nilreports success to the caller while the directory is left untouched at the old path and never appears at the new one — a silent data-visibility failure, which is the worst shape for a filesystem wrapper. The name filter is correctly skipped for directories too, so a destination like/renameddirthat does not match the regexp must not be rejected.Note the sibling
if dir { return nil }atregexpfs.go:43is indirOrMatchesand is correct — there,nilmeans "passes the filter". That one is deliberately left alone.Reproduction
Comparing
RegexpFsagainst its unfiltered source:The fix
if dir { - return nil + return r.source.Rename(oldname, newname) }Tests
TestRegexpFsRenameDirinregexpfs_test.go, run against both theMemMapFsandOsFsbackends. It asserts the source is gone, the destination exists, and the contents are readable through the new path.go test ./... -count=1→ 130 top-level PASS, 56 subtest PASS, 0 FAIL, exit 0.go vet ./...clean.afero,mem,tarfs,zipfsallok), so the suite introduced zero regressions.regexpfs_test.gopreviously had zero coverage ofRename. I checked the 30 open PRs: none touch it (#632RegexpFileis a different file, aboutWriterTo/ReaderFrom). Issue #327 is about file-handle names after rename and is unrelated.gcsfs/andsftpfs/are separate Go modules and so are not covered by the root./...; both are untouched.