Locating Mac OS X folders using URLForDirectory instead of FSFindFolder

Question

I have some old code that finds specific folders using the old FSFindFolder routine. Now I have the task of modernizing this code. At first using NSFileManager's URLForDirectory seem like the right choice. Unfortunately I found out that many of the folders you could locate using FSFindFolder are no longer supported by URLForDirectory.

The list of folders you can locate using FSFindFolder is very long and most of them are not useful to my anyway.

Here is a partial list of FSFindFolder constants that I do need to convert and their URLForDirectory equivalents:

FSFindFolder                    URLForDirectory
==============================  ===============
kDesktopFolderType              NSDesktopDirectory
kCachedDataFolderType           NSCachesDirectory
kApplicationSupportFolderType   NSApplicationSupportDirectory
kTemporaryFolderType            located by calling NSTemporaryDirectory()
kCurrentUserFolderType          located by calling NSHomeDirectory()
kSystemFolderType               Not Available
kPreferencesFolderType          Not Available
kTrashFolderType                Not Available
kAudioComponentsFolderType      Not Available
kVolumeRootFolderType           Not Available
kSharedUserDataFolderTypeNo     Not Available

My question: is there a standard way to locate paths to each of the folders marked "Not Available" without using FSFindFolder?

Fieldfare

Follow this link #18683845 – Epitomize

@hussain-shabbir Question 18683345 is about walking through the files in a folder - It has nothing to do with my question. My question is about locating specific folders. – Fieldfare

Can you please explain little bit more what you want to achieve. I mean what output you required?? – Epitomize

If i am not wrong you want to locate the path without using this FSFindFolder right?? – Epitomize

I have updated your solution, let me know is this the one which you wanted?? – Epitomize

Answer 1

I would recommend that modernizing code will, in most cases, mean shifting away from whatever you were using these folder locations for in the first place. For example, there's not much legitimate use for an equivalent of kSystemFolderType in modern code. You should examine each case where you're using these and ask what the right solution is to solve the high-level problem that that old implementation was solving.

If you really do need paths to some of these folders, your best bet is to look at the path that FSFindFolder() gives, find which NSSearchPathDirectory gets you closest, and then just write your code to get that from URLForDirectory:... and append the difference as a static relative path.

Some specific recommendations:

kPreferencesFolderType: use NSUserDefaults to store preferences; store non-defaults in Application Support

kTrashFolderType: use -[NSWorkspace recycleURLs:completionHandler:] or -performFileOperation:source:destination:files:tag: with NSWorkspaceRecycleOperation; only if necessary, use -[NSFileManager URLForDirectory:...] with NSTrashDirectory

kVolumeRootFolderType: if you're using this with a specific volume ref rather than a domain, use -[NSURL getResourceValue:forKey:error:] with key NSURLVolumeURLKey

kSharedUserDataFolderType: -URLForDirectory:... with NSUserDirectory and then append @"Shared" as a path component

kAudioComponentsFolderType: the Component Manager is deprecated; Apple says there's no exact replacement, but for some purposes Audio Component Services is appropriate.

Psalms

"Apple says..." is not good enough for me any more. I need standard folder locations to be consistence. Shifting away from the previous folder location means also shifting away from backward compatibility for my users. I have users that for the past 15 yeas or so have been saving their preferences to the folder at ~/Library/Preferences. Lately Apple has a new tune, where Preferences folder is not to be accessed directly. OTOH I'm afraid FSFindFolder will not be supported in future systems and so want to use modern Cocoa code. – Fieldfare

Answer 2

I'm going off of the legacy documentation for the definitions of the FSFindFolder constants. I will do the best I can to make educated guesses about how they map, so if I am wrong, please clarify and I'll update my answer.

[NSFilemanager URLForDirectory:inDomain:appropriateForURL:create:error:] (documentation)can help you find some of these items. It can find:

NSApplicationDirectory
NSDemoApplicationDirectory
NSDeveloperApplicationDirectory
NSAdminApplicationDirectory
NSLibraryDirectory
NSDeveloperDirectory
NSUserDirectory
NSDocumentationDirectory
NSDocumentDirectory
NSCoreServiceDirectory
NSAutosavedInformationDirectory
NSDesktopDirectory
NSCachesDirectory
NSApplicationSupportDirectory
NSDownloadsDirectory
NSInputMethodsDirectory
NSMoviesDirectory
NSMusicDirectory
NSPicturesDirectory
NSPrinterDescriptionDirectory
NSSharedPublicDirectory
NSPreferencePanesDirectory
NSApplicationScriptsDirectory
NSItemReplacementDirectory
NSAllApplicationsDirectory
NSAllLibrariesDirectory
NSTrashDirectory

In User, Local, Network and System domains.

That should take care of kTrashFolderType.

As far as I can tell, kSystemFolderType will always be the System folder in the root directory (eg /System) so you shouldn't have to search for it. kPreferencesFolderType specifies the Preferences folder in the System Folder. I'm not sure what this means, as there is no "preferences" folder in /System/Library There is however a folder at /Library/Preferences. This too is a static location.

Not sure about kAudioComponentsFolderType, kVolumeRootFolderType, and kSharedUserDataFolderTypeNo off-hand.

Corrigan