Fix FileManager's extended attribute symlink handling by SiliconA-Z · Pull Request #1623 · swiftlang/swift-foundation

SiliconA-Z · 2025-12-05T18:27:42Z

The if statement appears inverted: setxattr follows simlinks: lsetxattr does not.

Additionally, _extendedAttributes was ignoring simlinks entirely.

Both of these issues have been addressed.

Sources/FoundationEssentials/FileManager/FileManager+Utilities.swift

SiliconA-Z · 2025-12-08T21:06:14Z

@jmschonfeld ping?

SiliconA-Z · 2025-12-09T01:58:47Z

@jmschonfeld @compnerd ping?

jmschonfeld · 2025-12-09T02:16:06Z

@jmschonfeld @compnerd ping?

It's on my list to circle back and review when I have a moment - no need to ping 🙂. Will be working my way through the handful of PRs open to review

jmschonfeld · 2025-12-09T16:24:51Z

@swift-ci please test

Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift

compnerd

The code change looks fine, needs fixes for the tests.

SiliconA-Z · 2025-12-09T21:29:15Z

I fixed it, but also noticed we weren't passing followSymlinks to _extendedAttributes when the test failed on Darwin so. @compnerd

Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift

Sources/FoundationEssentials/FileManager/FileManager+Files.swift

SiliconA-Z · 2025-12-11T13:58:55Z

@jmschonfeld Can we please test and merge?

jmschonfeld · 2025-12-11T18:49:38Z

Sources/FoundationEssentials/FileManager/FileManager+Files.swift

        var extendedAttrs: [String : Data] = [:]
        var current = keyList.baseAddress!
-        let end = keyList.baseAddress!.advanced(by: keyList.count)
+        let end = keyList.baseAddress!.advanced(by: size)


It looks like this was changed in a recent commit (hard to determine with force pushes rather than follow-on commits which are easier to review). Is there a reason you're switching to use the passed in size here rather than using the size of the allocation returned by the allocate function?

Yes — the size variable gets updated by the second listxattr/extattr_list_* call to reflect the actual number of bytes written.

In that case if size is potentially different (if the file system changes and the number of attributes are removed) can we add an assertion that size <= keyList.count? In most cases I assume this shouldn't be an issue, but I'm wary that trusting this value could in some edge case inadvertently introduce a buffer overread here if size somehow becomes something larger than our allocation after it is overwritten.

If anything I'd say the opposite is more likely to happen: if keyList.count changes between allocation and read then this can happen.

I don't think I'm fully following - in what situation would keyList.count change?

Maybe this is best for another PR. I'll revert it.

jmschonfeld · 2025-12-11T18:51:04Z

Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift

+                if error.code == .featureUnsupported { return }
+                guard let posix = error.underlying as? POSIXError else { throw error }
+                #if canImport(Darwin)
+                guard posix.code == .ENOTSUP || posix.code == .EOPNOTSUPP else { throw error }


Is there a reason why ENOTSUP is guarded for Darwin only here?

Because ENOTSUP is not an error code on Linux.

I tried and it didn't compile.

ENOTSUP is an error code on Linux as far as I can tell if I'm reading the man pages correctly, but it looks like it has the same value as EOPNOTSUPP so there's no distinction. It looks like we also don't have a POSIXErrorCode.EOPNOTSUP for it which is likely the compilation error you were seeing (either intentionally because it's not necessary or just because nobody has ended up needing it). If that's the case, can you leave a comment about why this distinction is here so it's clear that ENOTSUP is not distinct from EOPNOTSUPP on non-Darwin platforms?

SiliconA-Z · 2025-12-11T21:09:32Z

I think this is as heavy as change now as it should get. We should merge this

I'll save the count and size replacement for another PR. That has been reverted back @jmschonfeld

jmschonfeld · 2025-12-12T17:51:59Z

@swift-ci test

SiliconA-Z · 2025-12-12T18:20:06Z

Test failed because of a permission error on linux. @jmschonfeld what to do? How am I supposed to fix that in the test

SiliconA-Z · 2025-12-12T18:27:30Z

Ugh I had to fix the tests to use rawvalue. The previous version passed locally, but not on the CI. My bad...

Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift

The if statement appears inverted: setxattr follows simlinks: lsetxattr does not. Additionally, _extendedAttributes was ignoring simlinks entirely. Both of these issues have been addressed.

jmschonfeld · 2025-12-16T20:54:26Z

@swift-ci please test

SiliconA-Z · 2025-12-16T21:45:26Z

It passed @jmschonfeld

SiliconA-Z · 2026-01-04T18:51:57Z

@jmschonfeld Is this good to go?

jmschonfeld · 2026-01-09T21:22:59Z

Apologies for the delay here. I was thinking on this behavior a bit more and I realized I may have misunderstood the base of the problem here. Today it looks like the behavior is reading xattrs always follows symlinks and setting xattrs does not follow symlinks on Darwin but does follow symlinks on Linux, all because it either ignored followSymlinks: or inverted it. Your change originally seemed reasonable which updates the functions to respect the followSymlinks: parameter which is always passed in as false meaning that these will now always not follow symlinks.

However, the rest of setAttributes/attributesForItem where these are called from will always traverse symlinks. In general, most of the FileManager APIs traverse symlinks (compared to URL APIs which typically do not traverse symlinks). So I think while this change is headed in the right direction by respecting the followSymlinks: flag, I think it uncovers another issue: that we are passing followSymlinks: false. This corrects the behavior of this function, but due to this I think it will introduce an inconsistency in APIs like setAttributes/attributesForItem.

What do you think about changing the call sites to followSymlinks: true now that the function behaves correctly? That means the behavior will be consistent with the rest of the FileManager APIs, but will require updating the tests. Thoughts?

SiliconA-Z · 2026-01-09T21:50:24Z

I am for it

jmschonfeld reviewed Dec 5, 2025

View reviewed changes

Sources/FoundationEssentials/FileManager/FileManager+Utilities.swift Show resolved Hide resolved

SiliconA-Z force-pushed the mistake branch from 87e9b15 to 1e3f4fa Compare December 5, 2025 22:04

SiliconA-Z requested a review from jmschonfeld December 5, 2025 22:10

jmschonfeld reviewed Dec 9, 2025

View reviewed changes

Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift Outdated Show resolved Hide resolved

compnerd reviewed Dec 9, 2025

View reviewed changes

SiliconA-Z force-pushed the mistake branch from 1e3f4fa to ccbe0e1 Compare December 9, 2025 21:26

SiliconA-Z requested review from compnerd and jmschonfeld December 9, 2025 21:29

SiliconA-Z force-pushed the mistake branch 3 times, most recently from 406328d to e1179f0 Compare December 9, 2025 21:36

jmschonfeld reviewed Dec 9, 2025

View reviewed changes

Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift Outdated Show resolved Hide resolved

SiliconA-Z requested a review from jmschonfeld December 10, 2025 14:11

SiliconA-Z force-pushed the mistake branch 2 times, most recently from 5505996 to 0c68c6a Compare December 10, 2025 15:36

jmschonfeld reviewed Dec 10, 2025

View reviewed changes

Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift Outdated Show resolved Hide resolved

SiliconA-Z force-pushed the mistake branch 2 times, most recently from bd02eaa to b179951 Compare December 10, 2025 17:44

SiliconA-Z requested a review from jmschonfeld December 10, 2025 17:44

jmschonfeld reviewed Dec 10, 2025

View reviewed changes

Sources/FoundationEssentials/FileManager/FileManager+Files.swift Outdated Show resolved Hide resolved

SiliconA-Z force-pushed the mistake branch 3 times, most recently from 8956f2e to 979d225 Compare December 10, 2025 21:57

SiliconA-Z requested a review from jmschonfeld December 10, 2025 21:58

SiliconA-Z force-pushed the mistake branch from 5267a46 to 0dd4d06 Compare December 10, 2025 22:29

SiliconA-Z changed the title ~~Fix FileManager extended attribute symlink handling~~ Fix FileManager's extended attribute symlink handling Dec 10, 2025

SiliconA-Z force-pushed the mistake branch 2 times, most recently from 037f442 to 9e17700 Compare December 10, 2025 22:35

SiliconA-Z force-pushed the mistake branch from 9e17700 to d861864 Compare December 11, 2025 16:06

jmschonfeld reviewed Dec 11, 2025

View reviewed changes

SiliconA-Z requested a review from jmschonfeld December 11, 2025 19:10

SiliconA-Z force-pushed the mistake branch from 2b6e76f to a93421d Compare December 12, 2025 18:19

SiliconA-Z force-pushed the mistake branch 4 times, most recently from fd46df6 to 3adb585 Compare December 12, 2025 18:26

jmschonfeld reviewed Dec 12, 2025

View reviewed changes

Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift Outdated Show resolved Hide resolved

Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift Outdated Show resolved Hide resolved

SiliconA-Z force-pushed the mistake branch from 3adb585 to 15e1703 Compare December 12, 2025 22:17

SiliconA-Z requested a review from jmschonfeld December 12, 2025 22:17

SiliconA-Z force-pushed the mistake branch 3 times, most recently from c685af8 to 8258e8f Compare December 15, 2025 22:37

Fix FileManager's extended attribute symlink handling

65c40d9

The if statement appears inverted: setxattr follows simlinks: lsetxattr does not. Additionally, _extendedAttributes was ignoring simlinks entirely. Both of these issues have been addressed.

SiliconA-Z force-pushed the mistake branch from 8258e8f to 65c40d9 Compare December 16, 2025 20:48

Conversation

SiliconA-Z commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

SiliconA-Z commented Dec 8, 2025

Uh oh!

SiliconA-Z commented Dec 9, 2025

Uh oh!

jmschonfeld commented Dec 9, 2025

Uh oh!

jmschonfeld commented Dec 9, 2025

Uh oh!

Uh oh!

compnerd left a comment

Choose a reason for hiding this comment

Uh oh!

SiliconA-Z commented Dec 9, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

SiliconA-Z commented Dec 11, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SiliconA-Z commented Dec 11, 2025

Uh oh!

jmschonfeld commented Dec 12, 2025

Uh oh!

SiliconA-Z commented Dec 12, 2025

Uh oh!

SiliconA-Z commented Dec 12, 2025

Uh oh!

Uh oh!

Uh oh!

jmschonfeld commented Dec 16, 2025

Uh oh!

SiliconA-Z commented Dec 16, 2025

Uh oh!

SiliconA-Z commented Jan 4, 2026

Uh oh!

jmschonfeld commented Jan 9, 2026

Uh oh!

SiliconA-Z commented Jan 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

SiliconA-Z commented Dec 5, 2025 •

edited

Loading