Checking if a URL is a directory

Using Swift
1

After some research, this is what I got:

var resultStorage: ObjCBool = false // true or false doesn't matter here, but
                                    // it has to be set before taking its
                                    // address, which we have to do below.

guard FileManager.default.fileExists(atPath: url.path, isDirectory: &resultStorage)
    else { fatalError("Handle case where url is not an existing file.") }

let isDir = resultStorage.boolValue // Finally!

Is this the recommended way to do something as elementary as checking if a given URL is a directory?

2

I do not know what the recommended way is, but something like

    let isDir = (try url.resourceValues(forKeys: [.isDirectoryKey])).isDirectory

would be an alternative.

4 Likes
3

Ah, much better, thanks!

4

I tried the following code (which is, in principle, the code above) and it does not work, files that are not a directory are judged being so:

extension URL {
    var isDirectory: Bool {
       (try? resourceValues(forKeys: [.isDirectoryKey]))?.isDirectory == true
    }
}

So how can I see if an URL points to a directory?

5

Can you provide an example of those files that are incorrectly judged as folders? Are they packages or what? Other than that, I'd try the two alternatives: one of which is mentioned above: FileManager.fileExists(atPath:isDirectory:) and another which is not: FileManager.attributesOfItem(atPath:). Note that the former method follows symlinks while the other two methods don't.

6

I tried the following code … and it does not work

This Works on My Machine™. Specifically, the following code running in a command-line tool built with Xcode 13.1 and running on macOS 11.6.1:

import Foundation

extension URL {
    var isDirectory: Bool {
       (try? resourceValues(forKeys: [.isDirectoryKey]))?.isDirectory == true
    }
}

func main() {
    var u = URL(fileURLWithPath: "/System/Library/Kernels/kernel")
    while u.path != "/" {
        print(u.path, "->", u.isDirectory)
        u.deleteLastPathComponent()
    }
}

main()

prints:

/System/Library/Kernels/kernel -> false
/System/Library/Kernels -> true
/System/Library -> true
/System -> true

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

4 Likes
7

Oh sorry huge (!) mistake on my side. Sorry for this. The code works indeed. Thank you for your time.

8

I'm doing a little research on exactly this question and though the thread mentions all the possible ways, I was hoping to find some clarity on the different methods.

Traditionally, I've used FileManager's fileExists(atPath:isDirectory:) because it seemed the oldest and hopefully most reliable (always fun to see an ObjcBool). In my internet travels (and discussed here in brief) are the three ways I have found:

extension URL {
    
    var isDirectory: Bool {
        get throws {
            try resourceValues(forKeys: [.isDirectoryKey]).isDirectory == true
        }
    }
}

extension FileManager {
    
    func isDirectory(atPath path: String) -> Bool? {
        var isDirectory: ObjCBool = false
        
        guard fileExists(atPath: path, isDirectory: &isDirectory) else {
            return nil
        }
        
        return isDirectory.boolValue
    }
    
    func isDirectory(atPath path: String) throws -> Bool {
        switch try attributesOfItem(atPath: path)[.type] as? FileAttributeType {
        case .typeDirectory:
            true
            
        default:
            false
        }
    }
}

I'm vaguely aware that resourceValues(forKeys:) caches values.

Are attributesOfItem(atPath:) and resourceValues(forKeys:) using the same API under the hood? Are both functions using cached values?

Is there any benefit to sticking with the older API over a newer (possibly cached) alternative? Personally, cached values (aka shared state) in a Sendable righteous world makes me hesitate.

I came here looking for answers and yes they're all here, but presented without comment.

Maybe this is a solved problem and any solution is foolproof enough? Anyone have any recommendations based on usage, speed, compatibility, gotchas/pitfalls, or known issues?

9

The best approach is gonna depend on the context:

  • How do you want to treat things that are neither files nor directories?

  • What layer of the stack are you working at? Folks working at the BSD layer have different options from folks working with Foundation.

  • Do you want just this ‘is a directory’ value? Or are you getting this value along with a bunch of other attributes?

  • Do you want this value for a single URL? Or are you iterating through the file system hierarchy and want the values for every URL you get back?

The last point is the most critical. If you’re working with a single URL then performance generally doesn’t matter, so you can use whatever API you like. However, if you’re working with a large bunch of URLs then choosing the right API can yield a massive performance win (or lose, depending on your perspective :-).

Specifically, when operating on high-latency file systems, like a network file system, it’s absolutely critical that you get all the attributes you need while you’re enumerating the directory. If you enumerate the directory and then get attributes for each item, the latencies add up and performance will tank [1].

That means using getattrlistbulk. Except that you don’t want to use getattrlistbulk because it’s really hard to call, so you’ll wanna use some sort of wrapper. The obvious wrapper is FileManager, where the contentsOfDirectory(at:includingPropertiesForKeys:options:) returns the contents of the directory as an array of URLs, with each URL holding the resource values you requested in its cache.

And that’s why I generally favour the resource value APIs. They were designed to get you on to this performance happy path.

If there are specific places where you’re worried about a resource value being cached inappropriately, deal with that using removeCachedResourceValue(forKey:) or removeAllCachedResourceValues(). But IME this is rarely needed.

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

[1] And I mean really tank. Imagine a directory with 50 items in it on a file server with a 100 ms latency. If you enumerate the directory properly, you can expect all your results in 100 ms. If you do it badly, that’ll take 5 seconds. Ouch!

4 Likes
10

I'm vaguely aware that resourceValues(forKeys:) caches values

Beware, the cached value is not revalidated until the next run loop invocation!

  • Create a file
  • call resource values on it - good
  • delete the file / make other changes
  • call resource values on it - it’s still there / unchanged

If there are specific places where you’re worried about a resource value being cached inappropriately, deal with that using removeCachedResourceValue(forKey:) or removeAllCachedResourceValues().

Good to know!

1 Like
11

To add: I believe the resource-aware variant of contentsOfDirectory that is recursive is FileManager.enumerator(at: includingPropertiesForKeys: options: errorHandler:)

1 Like
12

Thank you, this helps clear things up in a number of ways.

From what you're saying, the cached resource values are stored in URL and the FileManager API populates them according to the included keys. Its resourceValues all the way down, just some APIs populate them differently (getattrlistbulk vs. non-bulk NSURL.getResourceValue()).

Right now I'm just building a basic abstraction:

struct File {
    var location: URL
    private let manager: FileManager
}

In this case it would be better to ask the stored location URL for resourceValues (which get cached there), then to query the FileManager using location.path() which would re-build the URL each time and possibly need to re-populate the resourceValues. There's some assumptions there but hopefully my mental model of it is more accurate?

Since I'm mostly dealing in local files, I should really only be concerned about finding bottlenecks when I'm making a Sequence/Collection for subfolders and accessing attributes during iteration.

Thanks for putting things in practical context. Always appreciated :D

ps. researching getattrlistbulk, I found this article with details about performance you mention, more remote storage focused but it helped me understand the APIs better.

13

Wasn’t there a recent conversation about that not working?

Either way, the caching of resource values is definitely a two-edged sword.

Ah, yes. I always forget about this API because I have a general aversion to the type casting required by NSEnumerator. However, it’s definitely the best way to handle recursive enumeration.

Right. While network file systems bring this issue into stark relief, you’ll observe this phenomenon with local file systems too. You can think of the kernel as a very low-latency network file server (-: Every kernel call has a cost. getattrlistbulk has more overhead than readdir but, if you want attributes other than the name [1], readdir requires more kernel calls.

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

[1] Well, the name and the inode number.

1 Like