If reading with this option succeeds, then subsequent invocations of fileWrappers, regularFileContents, symbolicLinkDestinationURL, and serializedRepresentation sent to the file wrapper and all its child file wrappers will fail and return nil only if an actual error occurs (for example, the volume has disappeared or the file server is unreachable)—not as a result of the user moving or deleting files.

For performance reasons, NSFileWrapper may not read the contents of some file packages immediately even when this option is chosen. For example, because the contents of bundles (not all file packages are bundles) are immutable to the user, NSFileWrapper may read the children of such a directory lazily.

You can use this option to take a snapshot of a file or folder for writing later. For example, an application like TextEdit can use this option when creating new file wrappers to represent attachments that the user creates by copying and pasting or dragging and dropping from the Finder to a TextEdit document. Don't use this option when reading a document file package, because that would cause unnecessarily bad performance. For example, an application wouldn't use this option when creating file wrappers to represent attachments as it's opening a document stored in a file package.

Available in Mac OS X v10.6 and later.

Whether file mapping for regular file wrappers is disallowed.

You can use this option to keep NSFileWrapper from memory-mapping files. This is useful if you want to make sure your application doesn't hold files open (mapped files are open files), therefore preventing the user from ejecting DVDs, unmounting disk partitions, or unmounting disk images. In Mac OS X v10.6 and later, NSFileWrapper memory-maps files that are on internal drives only. It never memory-maps files on external drives or network volumes, regardless of whether this option is used.

Available in Mac OS X v10.6 and later.