Creates a new BDirectory object that represents the directory as given by the arguments. See the analogous SetTo() functions for descriptions of the flavorful constructors.

• The default constructor does nothing; it should be followed by a call to SetTo().

• The copy constructor points the BDirectory to the same directory as is represented by the argument. The two objects have their own entry iterators.

To check to see if an initialization was successful, call InitCheck().

Deletes the object.

Returns true if path or entry is contained within this directory, or in any of its subdirectories (no matter how deep). You can use the nodeFlags argument to limit the search to a particular flavor of node:

These functions create a new file, directory, or symbolic link. The new node is located at path. If path is relative, it's reckoned off of the directory represented by this BDirectory; if it's absolute, the path of this BDirectory is ignored.

• CreateFile() fails if the file already exists and failIfExists is true. If the flag is false (and the file exists), the old file is clobbered and a new one is created. If successful, the BFile argument that you pass in is opened on the new file in B_READ_WRITE mode.

• CreateDirectory() and CreateSymLink() fail if path already exists—you can't clobber an existing directory or link.

• The linkToPath argument (CreateSymLink()) is the path that the new symbolic link will be linked to.

The object argument (the BDirectory, BFile, or BSymLink) may be NULL. If the function fails, the object argument, if non-NULL, is Unset().

Finds the entry with the given name, and sets the second argument to refer to that entry.

• path must be a relative pathname. It's reckoned off of the BDirectory's directory.

• You are allowed to look for "." and "..". The former represents this directory's entry. The latter refers to this directory's parent.

• The entry argument must be allocated before it's passed in (it needn't be initialized).

• The traverse applies to symbolic links: If the flag is true, the link is traversed. If it's false, you get the BEntry that points to the link itself.

If path isn't found, the second argument is automatically Unset(). To find out why the lookup failed, invoke InitCheck() on the entry argument:

BEntry entry;
status_t err;

if (dir.FindEntry("aFile", &entry) != B_OK) {
   err = entry.InitCheck();
}

The direct return value is also informative, but it may not be as precise as the InitCheck() value.

Initializes entry to represent this BDirectory. If the initialization fails, entry is Unset().

The three GetNext…() functions retrieve the "next" entry that lives in the BDirectory and returns it as a BEntry, entry_ref, or dirent structure.

• GetNextEntry() returns the entry as a BEntry object. If traverse is true and the entry is a symbolic link, the link is traversed. In other words, entry could end up being in a different directory than the one referred to by this. When all entries have been visited, the function returns B_ENTRY_NOT_FOUND. The entry argument must be allocated before it's passed in.

• GetNextRef() return the next entry in ref. Since an entry_ref doesn't supply enough information to determine if the entry is a link, there's no question of traversal: The entry_ref points to exactly the next entry. When all entries have been visited, the function returns B_ENTRY_NOT_FOUND. The ref argument must be allocated before it's passed in.

• GetNextDirents() returns some number of dirent structures, either as many as can be stuffed into buf (where bufsize gives the size of buf), or count structures, whichever is smaller. The function returns the number of structures that were stuffed into buf; when all entries have been visited, it returns 0.

Warning

Currently, GetNextDirents() only reads one dirent at a time, no matter how many you ask for.

GetNextEntry() and GetNextRef() are reasonably clear; the dirent version deserves more explanation. You'll find this explanation (and an example) in the BEntryList class. Also, keep in mind that the set of candidate entries is different for the dirent version: GetNextDirents() finds all entries, including the entries for "." and "..". The other two versions skip these entries.

When you're done reading the BDirectory's entries, you can rewind the object's entry iterator by calling Rewind().

CountEntries() returns the number of entries (not counting "." and "..") in the directory.

Warning

Never call CountEntries() while you're iterating through the directory. CountEntries() does a rewind, iterates through the entries, and then rewinds again.

Gets the stat structure for the entry designated by path. path may be either absolute or relative; if it's relative, it's reckoned off of the BDirectory's directory. This is, primarily, a convenience function; but it's also provided for efficiency.

Returns true if this BDirectory represents a root directory. A root directory is the directory that's at the root of a volume's file hierarchy. Every volume has exactly one root directory; all other files in the volume's hierarchy descend from the root directory.

Closes the BDirectory's current directory (if any), and initializes the object to open the directory as given by the arguments.

• In the path version, path can be absolute or relative, and can contain "." and ".." elements. If path is relative, it's reckoned off of the current working directory.

• In the dir/path version, path must be relative. It's reckoned off of the directory given by dir.

If the specification results in a symbolic link that resolves to a directory, then the linked-to directory is opened. If the specification is (or resolves to) a regular file, the initialization fails.

In the expression

BDirectory a = b;

BDirectory a is initialized to refer to the same directory as b. To gauge the success of the assignment, you should call InitCheck() immediately afterwards. Assigning a BDirectory to itself is safe.

Assigning from an uninitialized BDirectory is "successful": The assigned-to BDirectory will also be uninitialized (B_NO_INIT).

Creates all missing directories along the path specified by path.

• The pathname can be absolute or relative. If it's relative, the path is reckoned of the current working directory. If any symlinks are found in the existing portion of the path, they're traversed.

• path can contain ".", but it may not contain "..".

• mode is the permissions setting (typically expressed as an octal number) that's assigned to all directories that are created. To set the directories to be readable, writable, and "enterable" by all (for example), you would set the mode to 0777.

Declared in: storage/FindDirectory.h

Note

The first version of this function can be used in either C or C++ code. The second version is for C++ code only.

Finds the path to the directory symbolized by which and copies it into path_string, or uses it to initialize path_obj.

• The create_it argument tells the function to create the directory if it doesn't already exist.

• volume identifies the volume (as a dev_t identifier or BVolume object) on which you want to look. The C++ default (NULL) means to look in the boot volume.

• The length argument (first version only) gives the length of path.

The directory_which constants are described below.

Declared in: storage/FindDirectory.h

These constants are used when calling the find_directory() function to determine the pathname of a particular directory of interest.

B_DESKTOP_DIRECTORY and B_TRASH_DIRECTORY are per-volume directories; if you don't specify the volume you wish to locate these directories on, find_directory() will assume you mean the boot disk.

B_APPS_DIRECTORY and B_PREFERENCES_DIRECTORY are global directories, and always refer to the standard apps and preferences directories.

The B_BEOS_* constants refer to BeOS-owned directories, the B_COMMON_* constants refer to directories that are common to all users of the system, and the B_USER_* constants refer to the current user's directories (currently these are all in a subtree rooted at /boot/home, but when multiuser support is implemented in a future version of BeOS, these won't necessarily all be the same anymore).

In general, global application and system settings should be kept in B_COMMON_*; while settings that each user should be able to configure individually should be kept in B_USER_*.

By using these constants properly, your code will be compatible with future generations of the BeOS.