-
Notifications
You must be signed in to change notification settings - Fork 214
Fix FileManager's extended attribute symlink handling #1623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
@jmschonfeld ping? |
|
@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 |
|
@swift-ci please test |
Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift
Outdated
Show resolved
Hide resolved
compnerd
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code change looks fine, needs fixes for the tests.
|
I fixed it, but also noticed we weren't passing followSymlinks to _extendedAttributes when the test failed on Darwin so. @compnerd |
406328d to
e1179f0
Compare
Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift
Outdated
Show resolved
Hide resolved
5505996 to
0c68c6a
Compare
Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift
Outdated
Show resolved
Hide resolved
bd02eaa to
b179951
Compare
Sources/FoundationEssentials/FileManager/FileManager+Files.swift
Outdated
Show resolved
Hide resolved
8956f2e to
979d225
Compare
|
@swift-ci please test |
5267a46 to
0dd4d06
Compare
037f442 to
9e17700
Compare
|
@jmschonfeld Can we please test and merge? |
| var extendedAttrs: [String : Data] = [:] | ||
| var current = keyList.baseAddress! | ||
| let end = keyList.baseAddress!.advanced(by: keyList.count) | ||
| let end = keyList.baseAddress!.advanced(by: size) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes — the size variable gets updated by the second listxattr/extattr_list_* call to reflect the actual number of bytes written.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If anything I'd say the opposite is more likely to happen: if keyList.count changes between allocation and read then this can happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I'm fully following - in what situation would keyList.count change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this is best for another PR. I'll revert it.
| 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 } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why ENOTSUP is guarded for Darwin only here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because ENOTSUP is not an error code on Linux.
I tried and it didn't compile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
|
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 |
|
@swift-ci test |
|
Test failed because of a permission error on linux. @jmschonfeld what to do? How am I supposed to fix that in the test |
fd46df6 to
3adb585
Compare
|
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
Outdated
Show resolved
Hide resolved
Tests/FoundationEssentialsTests/FileManager/FileManagerTests.swift
Outdated
Show resolved
Hide resolved
The if statement appears inverted: setxattr follows simlinks: lsetxattr does not. Additionally, _extendedAttributes was ignoring simlinks entirely. Both of these issues have been addressed.
The if statement appears inverted: setxattr follows simlinks: lsetxattr does not.
Additionally, _extendedAttributes was ignoring simlinks entirely.
Both of these issues have been addressed.