Note that there are some explanatory texts on larger screens.

plurals
  1. PODoes the isDirectory parameter to +[NSURL fileURLWithPath:isDirectory:] need to be correct?
    primarykey
    data
    text
    <p>I have long been using <code>+[NSURL fileURLWithPath:]</code> because it's convenient, but in profiling I found that this was a source of bottlenecks because it queries the filesystem before calling down to <code>+[NSURL fileURLWithPath:isDirectory:]</code> (or the Core Foundation equivalent):</p> <blockquote> <p>This method assumes that <code>path</code> is a directory if it ends with a slash. If <code>path</code> does not end with a slash, the method examines the file system to determine if <code>path</code> is a file or a directory. If <code>path</code> exists in the file system and is a directory, the method appends a trailing slash. If <code>path</code> does not exist in the file system, the method assumes that it represents a file and does not append a trailing slash.</p> </blockquote> <p>I would like to avoid this overhead if possible. But I don’t always know ahead of time whether the URL I’m constructing is a directory. For example, I may just be given a path, or I may be given a directory and the name of an item (of unknown type) therein. My question is, is it OK to always pass <code>NO</code> for <code>isDirectory</code> even though this may turn out not to be accurate?</p> <p>In particular, I want to make sure this doesn’t mess up <code>-[NSURL getResourceValue:forKey:error:]</code> and <code>NSFileManager</code>.</p> <p>Some basic testing did not reveal any bad consequences to this optimization, but that doesn’t mean there aren’t any. It’s not fully clear to me <em>why</em> <code>NSURL</code> cares about <code>isDirectory</code> in the first place. Looking at the <a href="http://opensource.apple.com/source/CF/CF-744.19/CFURL.h" rel="nofollow">CFURL</a> <a href="http://opensource.apple.com/source/CF/CF-744.19/CFURL.c" rel="nofollow">source</a>, the code seems to try to make sure that directory paths always end with a slash. But, other than for display purposes, it’s not clear to me why this would matter for filesystem paths. (This was never an issue when using <code>NSString</code> to represent paths.) The documentation for <code>+[NSURL fileURLWithPath:isDirectory:]</code> says that <code>isDir</code> is:</p> <blockquote> <p>A Boolean value that specifies whether <code>path</code> is treated as a directory path when resolving against relative path components. Pass <code>YES</code> if the path indicates a directory, <code>NO</code> otherwise.</p> </blockquote> <p>Indeed, if I use <code>-[NSURL initWithString:relativeToURL:]</code>, the new URL does not include the last component of <code>baseURL</code> unless it was created with <code>YES</code> for <code>isDirectory</code>. However, I don’t think I’ve ever called this method, and it doesn’t seem like the system would need to do so on my behalf (for the above use cases). I note that <code>-[NSURL URLByAppendingPathComponent:]</code> inserts a slash if necessary, rather than assuming that the <code>IS_DIRECTORY</code> flag is correct. So, other than creating relative URLs, does this flag matter? Even if I wanted to, it does not seem possible in the general case to always pass in the correct value. The filesystem could always change out from under me. Nor can the system always determine it if I use <code>+[NSURL fileURLWithPath:]</code> because the path might not yet exist in the filesystem.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload