---

Portable File-System Operations

When you find, move, or delete files, do not assume that files are in set locations. If you include hard-coded paths, the portability and longevity of your code could suffer. The reasons behind this caution range from the obvious to the not-so-obvious.

As an example of the obvious, consider the user's home directory. There is no way your program can "know" (before doing the appropriate queries, that is) the name of the logged-in user's home directory and the location of that directory. The home directory can be named anything, the volume of the home directory can be named anything (and does not have to be the root volume), and the path between the volume and the home directory can be anything.

Even hard-coding system directories may cause a problem. For example, Apple's public frameworks are currently located at /System/Library/Frameworks on the root volume. But this location could change at a future date (who knows?), and any legacy code that relies on hard-coded paths to these frameworks would break.

For these reasons, before you perform many file-system operations, you should use one of the APIs that help you to locate standard directories in the file system. The first API is a Cocoa one: some of the functions and related constants defined in NSPathUtilities.h. The second is a Carbon API: the Folder Manager's FSFindFolder function, which is defined in the Core Services umbrella framework (Carbon Core subframework). Both APIs allow you to search for frameworks, applications, documents, and other resources across file-system domains. The two APIs are also similar in that both use constants to specify well-known directories and domains.

However, there are some differences in the domains and directories covered. Although you may use one or the other, the Cocoa API is recommended. See the task “Locating Directories on the System” for the procedures (and examples) of using these APIs in a Cocoa program.

---