On Apr 11, 2005 11:34 AM, Jeffrey Hutzelman <[EMAIL PROTECTED]> wrote:
> 
> 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.
> 

I suppose this behavior is convenient for shell scripts so you don't
go fork-happy calling fs.  However, I think it would be preferable to
have afs_symlink() do the right thing (TM) from any arbitrary unix
application's perspective, which means create a symlink no matter what
the heck is the contents of the link target, that's how DCE/DFS
handles it going back at least as far as 1.2.2.

I've attached a small (preliminary) patch that makes things behave
more like DFS.  It adds a new pioctl (VIOC_CREATE_MT_PT), and updates
fs.  There are probably other places that need updating (libadmin?,
src/JAVA?).  It works in my environment, but the pioctl number isn't
registered yet (I temporarily assigned it one from the legacy
range...), and I was too lazy to write the autoconf glue for those of
you who want to keep the old semantics ;-)
If there's some consensus, I'll finish it up and submit.

-- 
Tom Keiser
[EMAIL PROTECTED]

Attachment: mkmount-pioctl.patch
Description: Binary data

Reply via email to