D21643 "fixes" this by using copy(). However:

Filesystem::copyFile() has only one callsite, in lint, and it is only used to copy file permissions before writing a corrected file. On non-Windows systems, the implementation is cp -p, with -p ("preserve a bunch of file attributes") as the critical piece.

It's not clear to me if copy() copies all permissions/attributes (or if this is even meaningful on Windows). It seems like it works in Git bash for me, but I think Git bash is just using a filename heuristic on NTFS since NTFS doesn't support an executable bit, e.g. see here:

https://stackoverflow.com/questions/25730041/updating-file-permissions-with-git-bash-on-windows-7

So, likely:

• Git +x must be managed explicitly in Windows on NTFS (git update-index --chmod=+x scripts/script.sh).
• Since we're always eventually writing a file with the same path and name, we get the right result "for free" (on Windows + NTFS) no matter what, even if the intermediate file doesn't actually have the right permissions in NTFS and/or Git and/or Git Bash (MINGW), unless lint is changing +x on the file, which it currently never can.
• Unclear what happens if you have a Windows drive with a filesystem other than NTFS. I don't have any on hand and am not ambitious enough to format a disk to test this.

Upshot:

• Windows with non-NTFS filesystems might lose +x when a +x file is modified by lint, but this is a lot of work to test and might affect zero or nearly-zero users even if it does happen.
• Linters which add or remove +x (these currently do not exist) likely don't work on NTFS (and can't work naively: they must execute raw git commands).
• Filesystem::copyFile() could be removed, and the single callsite could be replaced with Filesystem::createNewFileWithSamePermissionsAs($src, $dst). This would, in theory, improve performance slightly when linting very large files (by omitting an unnecessary copy).
• copy() on Windows might also drop other permissions or otherwise produce an imperfect copy -- I'm not a Wizard Who Knows A Lot About Windows Filesystems -- but I couldn't find anything by poking at it for a bit.