Restore symlink mtime on Linux after extracting an entry

[odrobnik]

Summary

Linux extraction quietly drops the modification date of every symlink entry today. The fix is to call the existing setSymlinkModificationDate helper from the Linux branch instead of taking the blanket Apple-only no-op.

Background

FileManager.setAttributes(_:ofItemAtURL:traverseLink:) splits on platform:

#if os(macOS) || os(iOS) || os(tvOS) || os(visionOS) || os(watchOS)
    try self.setSymlinkPermissions(posixPermissions, ofItemAtURL: url)
    try self.setSymlinkModificationDate(modificationDate, ofItemAtURL: url)
#else
    // Since non-Darwin POSIX platforms ignore permissions on symlinks and
    // swift-corelibs-foundation currently doesn't support setting the
    // modification date, this codepath is currently a no-op on these
    // platforms.
    return
#endif

The comment is half right:

• Permissions — yes, Linux ignores symlink permission bits at the kernel level, regardless of what lchmod(2) does, so leaving the permission half off matches reality.
• Modification date — but lutimes(2) writes to the symlink itself rather than chasing the target, and Glibc has shipped it since 2.6. The existing setSymlinkModificationDate already calls it correctly. The only reason it wasn't running on Linux is that the entire call site was Apple-gated. The "swift-corelibs-foundation doesn't support …" half of the comment is true for FileManager.setAttributes(_:ofItemAtPath:), but ZIPFoundation is going straight to libc anyway, so it doesn't depend on that.

So Linux extraction loses symlink mtimes on every archive, which sometimes matters for tooling that walks extracted trees by timestamp.

Change

Add a #elseif os(Linux) branch to the call site that calls only setSymlinkModificationDate. No definition changes — setSymlinkModificationDate itself was already correct and accessible, just unused.

#if os(macOS) || os(iOS) || os(tvOS) || os(visionOS) || os(watchOS)
    // setSymlinkPermissions + setSymlinkModificationDate
#elseif os(Linux)
    // setSymlinkModificationDate only (Linux ignores symlink permission bits)
#else
    // Bionic / Windows: still a no-op
    return
#endif

Bionic falls through to the no-op because its lutimes is __INTRODUCED_IN(26) (not safe to lean on at low NDK targets) and Windows has no equivalent symlink-targeted utimes call. Both can be revisited in a follow-up — out of scope here.

Validation

Built clean on macOS (Swift 6.3, Xcode 26) — Build complete!. Full swift test run shows the same 2 pre-existing failures the unmodified development branch has (testCreateZIP64ArchiveWithLargeSize — a Version enum mirror-string format mismatch unrelated to anything here); all other 129 tests pass.

I don't have a Linux box wired up to run the test target on, but the code path is straightforward — setSymlinkModificationDate already had test coverage on Apple platforms that exercises exactly this lutimes call. Happy to add a Linux-only XCTest if you'd prefer (the attributes round-trip would just need to assert on the extracted symlink's Date instead of returning early).

Out of scope

• Symlink permission preservation on Linux. Drop entirely if you want the comment to be precise — the kernel ignores it, so there's nothing to preserve.
• Bionic + Windows symlink mtime. Bionic's utimensat(AT_FDCWD, path, &times, AT_SYMLINK_NOFOLLOW) is the obvious workaround for Android once a maintainer is happy bumping the supported NDK floor; Windows would need a SetFileInformationByHandle call against an opened reparse-point handle.

Related: weichsel/ZIPFoundation#380 is my Android compile fix. This PR is independent and doesn't depend on it landing first.

[weichsel]

I'd just say "Other platforms" here (vs. Windows & Bionic)

[weichsel]

Changes look good.
Can you please move the
testInvalidSymlinkCompressionMethodErrorConditions
testSymlinkModificationDateTransferErrorConditions
tests from the darwinOnlyTests to the allTests list. They are also relevant on Linux now.