FoundationEssentials: try to make the file atomic behaviour more robust

[compnerd]

We have observed ERROR_ACCESS_DENIED in CI on
SetRenameInformationFile. Try to make the path more robust by first performing a kernel based rename with POSIX semantics. This requires Windows 10 1809+. If that is unsuccessful, verify that attributes are not to blame.

A failure may still occur if the file is on a different volume. In such a case, fallback to the MoveFileExW operation to perform a copy + delete operation.

Hopefully this should make the implementation more robust to failures.

[parkera]

Any test cases we could add alongside this change?

[jmschonfeld]

Could we also add a unit test for this? Even if the unit test can't reliably cause this issue 100% of the time, the example that @bnbarham mentioned in swiftlang/swift#83606 (comment) might be good to add as a test (but rewritten to use Swift concurrency instead of dispatch)

[compnerd]

How do we want to integrate the test case that @bnbarham and I were using?

[bnbarham]

How do we want to integrate the test case that @bnbarham and I were using?

How about something like the following in DataIOTests?

  @Test
  func atomicWrite() async throws {
    let data = generateTestData()

    await withThrowingTaskGroup(of: Void.self) { group in
      for _ in 0..<8 {
        group.addTask { [url] in
          #expect(throws: Never.self) {
            try data.write(to: url, options: [.atomic])
          }
        }
      }
    }

    let readData = try Data(contentsOf: url, options: [])
    #expect(readData == data)
  }

[jmschonfeld]

This LGTM, thanks! @bnbarham mentioned wanted to get this into release/6.2, is that still the desire? If so, right now we're currently automerging forward from release/6.2 to main so I think we'd want to re-target this PR to release/6.2 if that's where we want to land this (@parkera is that still our preferred process?)

[bnbarham]

is that still the desire?

I'd actually like to get this into release/6.2.0 if we think it's safe enough for the initial 6.2 release. But definitely release/6.2 if not. The issue this fixes in swift-driver is actually very likely to happen, assuming that any command in a build ends up needing response files.

[compnerd]

Let me cherry-pick this up to the release/6.2 branch.

[compnerd]

#1485 is the 6.2 cherry-pick; I don't have a strong opinion on which way we handle this (merge this and merge the other one or merge the other one and let the auto-merger handle the rest).

[compnerd]

@swift-ci please test