[JadeSkaggs]

Why this PR

Windows-native Git can fail to write objects on a macOS-hosted SMB share backed by APFS. In the reproduced setup, even git add in a fresh repository fails with:

error: unable to write file .git/objects/<object-id>: Permission denied
fatal: adding files failed

This prevents normal Windows development against the shared repository. The failure bypasses an existing APFS workaround introduced by #4527, rather than requiring a new SMB implementation.

Cause and change

Git makes a temporary loose object read-only before renaming it into place. On the affected share, CreateFileW(source, DELETE, ...) returns ERROR_ACCESS_DENIED for that read-only source.

The POSIX rename path introduced in 391bceae435 returns immediately when opening the source fails. That skips the common error handling, including the existing workaround that clears the source's read-only attribute, retries with MoveFileExW(), and restores the attributes on success or failure.

This five-line change saves the error and routes it through that existing handling. The POSIX rename path is unchanged when opening the source succeeds.

Validation

Built the clean source at 5cf10d74486d1e59b9ae6cedaedb4e26314e1557, then rebuilt with only this patch using the same compiler, dependencies, and build configuration.

Executable	Local Windows storage	Actual Mac SMB/APFS share
Unpatched	Passed the focused checks	Failed at git add with the loose-object permission error
Patched	Passed the focused checks	Passed the focused checks

The scripted end-to-end checks ran 25 Git commands and 78 passing assertions per location against the patched executable, with zero timeouts. One rename deliberately exits nonzero to test failure preservation. Coverage includes:

• Init, add, two commits, stored contents, and checkout in both directions.
• Relative and absolute linked worktree creation, actual gitfile link modes, clean status, removal, and no stale registrations.
• Reflogs retaining commit and checkout entries.
• Forced replacement of an existing read-only destination by a read-only source, checking contents, attributes, and staged entries, followed by a successful commit.
• A destination held open without delete sharing: the failed rename preserves both files, the source's read-only attribute, and the index, and leaves no index lock.
• git fsck --full --no-dangling and final clean status.

Existing upstream tests also passed on local storage:

Suite / selection	Result
t7001-mv	58 passed; 6 skipped for platform prerequisites
t2400-worktree-add	235 passed; 2 skipped for platform prerequisites
t2403-worktree-move	34 passed
t0610-reftable-basics: “ref transaction: many concurrent writers”	Selected test passed; the other 90 tests were skipped by selection

The concurrent-writers check exercises the workload for which the newer POSIX rename behavior matters.

Scope and limitations

• Reflogs were enabled. The SMB checks used windows.appendAtomically=false for the separate reflog append issue; this patch does not address that issue.
• Validation used an MSVC x64 Release build, CMake 4.4.4, and static zlib 1.3.2. Optional HTTP, Expat, iconv/gettext, and PCRE2 dependencies were disabled.
• The share-specific checks are an external scripted reproduction; no new in-tree test is included. The complete upstream suite and macOS Git / cross-OS checkout handoff were not tested.
• PowerShell fixture cleanup initially encountered access denial and succeeded after retries. All fixtures were removed; the cause of that separate cleanup delay was not established.

[dscho]

The err_win_to_posix() function is pretty exhaustive in the range of values it handles. However, the code behind handle_rename_error is not.

How certain can we be that this innocuous change doesn't introduce a regression via previously-handled-but-now-no-longer error value? I don't see an adequate discussion of this in the commit message, either.