Visit The New, Modern Unix Linux Community

Linux and UNIX Man Pages

Test Your Knowledge in Computers #585
Difficulty: Easy
Most object oriented programming languages such as C++ and Java are class-based languages.
True or False?
Linux & Unix Commands - Search Man Pages

exchangedata(2) [osx man page]

EXCHANGEDATA(2) 					      BSD System Calls Manual						   EXCHANGEDATA(2)

NAME
exchangedata -- atomically exchange data between two files SYNOPSIS
#include <unistd.h> #include <sys/attr.h> int exchangedata(const char * path1, const char * path2, unsigned int options); DESCRIPTION
The exchangedata() function swaps the contents of the files referenced by path1 and path2 in an atomic fashion. That is, all concurrent pro- cesses will either see the pre-exchanged state or the post-exchanged state; they can never see the files in an inconsistent state. The data in all forks is swapped in this way. The options parameter lets you control specific aspects of the function's behaviour. Open file descriptors follow the swapped data. Thus, a descriptor that previously referenced path1 will now reference the data that's acces- sible via path2, and vice versa. In general, the file attributes (metadata) are not exchanged. Specifically, the object identifier attributes (that is, the ATTR_CMN_OBJID and ATTR_CMN_OBJPERMANENTID attributes as defined by the getattrlist(2) function) are not swapped. An exception to this general rule is that the modification time attribute ( ATTR_CMN_MODTIME ) is swapped. When combined, these features allow you to implement a 'safe save' function that does not break references to the file (for example, aliases). You first save the new contents to a temporary file and then exchange the data of the original file and the temporary. Programs that reference the file via an object identifier will continue to reference the original file, but now it has the new data. The path1 and path2 parameters must both reference valid files. All directories listed in the path names leading to these files must be searchable. You must have write access to the files. The options parameter is a bit set that controls the behaviour of exchangedata(). The following option bits are defined. FSOPT_NOFOLLOW If this bit is set, exchangedata() will not follow a symlink if it occurs as the last component of path1 or path2. RETURN VALUES
Upon successful completion a value of 0 is returned. Otherwise, a value of -1 is returned and errno is set to indicate the error. COMPATIBILITY
Not all volumes support exchangedata(). You can test whether a volume supports exchangedata() by using getattrlist(2) to get the volume capabilities attribute ATTR_VOL_CAPABILITIES, and then testing the VOL_CAP_INT_EXCHANGEDATA flag. ERRORS
exchangedata() will fail if: [ENOTSUP] The volume does not support exchangedata(). [ENOTDIR] A component of the path prefix is not a directory. [ENAMETOOLONG] A component of a path name exceeded NAME_MAX characters, or an entire path name exceeded PATH_MAX characters. [ENOENT] Either file does not exist. [EACCES] Search permission is denied for a component of the path prefix. [ELOOP] Too many symbolic links were encountered in translating the pathname. [EFAULT] path1 or path2 points to an invalid address. [EXDEV] path1 and path2 are on different volumes (mounted file systems). [EINVAL] path1 or path2 reference the same file. [EINVAL] You try to exchange something other than a regular file (for example, a directory). [EIO] An I/O error occurred while reading from or writing to the file system. SEE ALSO
getattrlist(2) HISTORY
A exchangedata() function call appeared in Darwin 1.3.1 (Mac OS X version 10.0). Darwin December 15, 2003 Darwin

Check Out this Related Man Page

LINK(2) 						      BSD System Calls Manual							   LINK(2)

NAME
link, linkat -- make a hard file link SYNOPSIS
#include <unistd.h> int link(const char *path1, const char *path2); int linkat(int fd1, const char *name1, int fd2, const char *name2, int flag); DESCRIPTION
The link() function call atomically creates the specified directory entry (hard link) path2 with the attributes of the underlying object pointed at by path1. If the link is successful, the link count of the underlying object is incremented; path1 and path2 share equal access and rights to the underlying object. If path1 is removed, the file path2 is not deleted and the link count of the underlying object is decremented. In order for the system call to succeed, path1 must exist and both path1 and path2 must be in the same file system. As mandated by POSIX.1, path1 may not be a directory. link() will resolve and follow symbolic links contained within both path1 and path2. If the last component of path1 is a symbolic link, link() will point the hard link, path2, to the underlying object pointed to by path1, not to the symbolic link itself. The linkat() system call is equivalent to link except in the case where either name1 or name2 or both are relative paths. In this case a relative path name1 is interpreted relative to the directory associated with the file descriptor fd1 instead of the current working directory and similarly for name2 and the file descriptor fd2. Values for flag are constructed by a bitwise-inclusive OR of flags from the following list, defined in <fcntl.h>: AT_SYMLINK_FOLLOW If name1 names a symbolic link, a new link for the target of the symbolic link is created. If linkat() is passed the special value AT_FDCWD in the fd1 or fd2 parameter, the current working directory is used for the respective name argument. If both fd1 and fd2 have value AT_FDCWD, the behavior is identical to a call to link(). Unless flag contains the AT_SYMLINK_FOLLOW flag, if name1 names a symbolic link, a new link is created for the symbolic link name1 and not its target. On OS X, not assigning AT_SYMLINK_FOLLOW to flag may result in some filesystems returning an error. RETURN VALUES
Upon successful completion, a value of 0 is returned. Otherwise, a value of -1 is returned and errno is set to indicate the error. ERRORS
link() will fail and no link will be created if: [EACCES] A component of either path prefix denies search permission. [EACCES] The requested link requires writing in a directory with a mode that denies write permission. [EACCES] The current process cannot access the existing file. [EDQUOT] The directory in which the entry for the new link is being placed cannot be extended because the user's quota of disk blocks on the file system containing the directory has been exhausted. [EEXIST] The link named by path2 already exists. [EFAULT] One of the pathnames specified is outside the process's allocated address space. [EIO] An I/O error occurs while reading from or writing to the file system to make the directory entry. [ELOOP] Too many symbolic links are encountered in translating one of the pathnames. This is taken to be indicative of a looping symbolic link. [EMLINK] The file already has {LINK_MAX} links. [ENAMETOOLONG] A component of a pathname exceeds {NAME_MAX} characters, or an entire path name exceeded {PATH_MAX} characters. [ENOENT] A component of either path prefix does not exist, or is a dangling symbolic link. [ENOENT] The file named by path1 does not exist, or is a dangling symbolic link. [ENOSPC] The directory in which the entry for the new link is being placed cannot be extended because there is no space left on the file system containing the directory. [ENOTDIR] A component of either path prefix is not a directory. [EPERM] The file named by path1 is a directory. [EROFS] The requested link requires writing in a directory on a read-only file system. [EXDEV] The link named by path2 and the file named by path1 are on different file systems. In addition to the errors returned by the link(), the linkat() system call may fail if: [EBADF] The name1 or name2 argument does not specify an absolute path and the fd1 or fd2 argument, respectively, is neither AT_FDCWD nor a valid file descriptor open for searching. [EINVAL] The value of the flag argument is not valid. [ENOTSUP] flag was not set to AT_SYMLINK_FOLLOW (some filesystems only) [ENOTDIR] The name1 or name2 argument is not an absolute path and fd1 or fd2, respectively, is neither AT_FDCWD nor a file descrip- tor associated with a directory. SEE ALSO
symlink(2), unlink(2) STANDARDS
The link() function is expected to conform to IEEE Std 1003.1-1988 (``POSIX.1''). The linkat() system call is expected to conform to POSIX.1-2008 . 4th Berkeley Distribution October 29, 2008 4th Berkeley Distribution

Featured Tech Videos