On Sunday, April 10, 2005 08:08:39 PM -0700 Christer Bern�rus <[EMAIL PROTECTED]> wrote:
On 10 apr 2005, at 18.50, Jeffrey Hutzelman wrote:
Fortunately, at least for AFS, no transition is required at all, because the problem simply does not exist. While it is true that AFS mount points are represented as symlinks whose target begins with # or % (denoting the type of mount point), the thing that makes them mount points and not symlinks is their mode. It is possible to create symlinks to targets starting with '#' or '%' by making an RXAFS_Symlink() call, and clients will treat such links correctly. It is simply not possible to create such links using the symlink() syscall on an OpenAFS client, because the cache manager interprets such requests as requests to create mount points.
This, IMHO, seems to be a very odd way of implementing things. If I get this right, first you create a new type of object in the file system, then you make a special RXAFS_api to be able to create the old type of object that would otherwise have been created, then you map over an existing API to create the new type of object, and finally create an administration application to use for creating the new type of object that internally will have to use the *old* API. Phew!
It sounds to me like you're confused.
symlink(2) is a system call. RXAFS_Symlink() is the corresponding fileserver RPC.
Both operations are used for creating symbolic links, and also for creating mount points. This is because as far as the fileserver is concerned, there is no difference between a mount point and a symbolic link(*) -- a mount point is just a symlink with a special mode, and only the client cares about that. Of course, this detail is hidden from user-mode applications; such a program cannot distinguish between mount points and ordinary directories except by using special pioctl() operations for manipulating mount points.
Now, the thing to bear in mind is that one of the IN arguments to RXAFS_Symlink is an AFSStoreStatus, containing various attributes of the link to be created, including its mode. So to create a mount point, the client simply passes in the correct mode. The symlink() syscall, however, does not take such an argument. So the OpenAFS cache manager's implementation of symlink() guesses what the application means, based on the first character of the provided link target. If the first character is '#' or '%', then it uses mode 0644, indicating a mount point; otherwise it uses mode 0755, indicating a symbolic link.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
_______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
