-
-
Notifications
You must be signed in to change notification settings - Fork 36
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
Fix Path.Finder use case when a hidden file and a regular subdirectory are in the same level #90
base: master
Are you sure you want to change the base?
Fix Path.Finder use case when a hidden file and a regular subdirectory are in the same level #90
Conversation
…y are in the same level Also update `isDirectory` usage to be more efficient, by passing `.isDirectoryKey` to `FileManager.DirectoryEnumerator` initialization.
an astounding PR. You deserve more kudos than I can give. Thank you. |
@mxcl glad you liked it and learned a new API - I had no idea Once CI passes - may I merge it? Do you think you could publish a new release? |
We have to continue to support the same set of Swifts or we need to bump the major. Swift 5.0 is not that old. But I dunno, what do you think? |
ugh, CI needs updates because github retires images bah |
@mxcl is there anything I can do to help here? |
CI/CD needs to pass. If you look at my contribution graph you can already see I basically only work on open source 7 days a week. CI/CD shit is hours and hours of tedious busywork. We need it to pass or we need to bump the major version. |
I know I know, I can deal with it. For some reason I forgot that CI could be changed in this PR itself. |
like I don't feel that is fair either. But I really have no time to mess with this :(
Ideally we don’t bump, we promise to work with the version matrix we test against. However if it cannot be helped I can make a judgement call. I get that very few people use these old Swifts anymore, but that is the promise we make with semantic versioning. Like my new project |
When using Path.swift to build a tool, I noticed it had a bug related to its implementation around
FileManager.DirectoryEnumerator
. Here is a sample use case, which I added a test case to cover.Imagine you have the following file tree:
When running
find()
on root, including hidden files, one would expect to get all files and directories - and this is working fine. However, when setting.hidden(false)
, only the directoryb
is returned - and notb/c
,b/c/bar.txt
, norb/foo.txt
.This happens because of these lines in the
next()
method inPath.Finder
:When finding the first hidden file or directory,
skipDescendants()
is called. And according to the docs, this is what it does:This means that, when the first hidden file is found, and
skipDescendants()
is called, all files and directories residing alongside the hidden file are skipped.This PR adds a check, and only calls
skipDescendants()
if the path in question is a directory - if it's just a file, then nothing should be skipped, as other sibling files or directories might be "waiting" to be enumerated.Additionally, I changed the
FileManager.DirectoryEnumerator
initialization to use a more modern API, that can receive a list ofURLResourceKey
s, and passes.isDirectoryKey
- this way, there's no need to do an extra disk read for eachisDirectory
check, as they're fetched on the enumeration stage and only read via aURL
'sURLResourceValues
.