[OpenAFS] Z:\ is not in the global hierarchy
Rodney M Dyer
rmdyer@uncc.edu
Fri, 05 Dec 2003 03:42:13 -0500
Jason,
We've been using the AFS client for Windows since it was first ported from
Unix. The problem you describe was the first issue we encountered with AFS
on Windows. The problem is, after we thought about it for a bit, it wasn't
a problem at all, we just had to change our paradigm.
Many Unix admins get used to the fact that everything is a directory "off
the root". Even network connections are "mounted off the root". This is a
Unix paradigm, not a Windows one. Unix is Unix, and Windows is Windows,
and never the two shall meet (if Microsoft has its way). When AFS was
ported to Windows it had to be "screwed" into the Windows paradigm of
drives and UNC paths. Currently, Windows simply has no way to view file
systems as mounted off of a single "root". Mostly this is due to backward
compatibility issues. Most applications are written to use the drive\path
designation, while others use the newer \\server\share\path (UNC)
designation. No Windows applications can specify files as
"\root\path\subpath\..." because in the Windows world there is no
abstraction of a "root" from the hardware devices. What would "root" refer
to? Besides you still have the forward and backward slash problem. Many
Windows apps think that "/" forward slash is for a command line options flag.
My first thought when AFS was first ported to Windows back in 96-97 was
that we would end up with AFS being mounted under "c:\afs". Unfortunately
at the time, the early NTFS file system didn't allow "mounting" of any
sort. Today with NTFS 5 (Win2k/XP) you can "mount" another "physical"
device anywhere in the file system tree using "mountvol". See...
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/standard/mountvol.asp
Or, alternatively you can create a reparse point (similar to, but not the
same as a symlink) with the "junction.exe" command from
sysinternals.com. A reparse point is a kind of executable stub that the OS
reads and executes upon file system traversal. The code in the stub tells
the OS what to do. The "fsutil" command that comes with XP and I think
Win2k allows viewing reparse points, but not creating them. See...
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/standard/fsutil.asp
For example, if I have a CDROM drive as D:\, I can make a reparse point
under "c:" to make "c:\cdrom" as in...
c:\>md "c:\cdrom"
c:\>junction c:\cdrom d:\
So when I perform a directory listing of "c:\cdrom", it now shows the
contents of the CD.
To remove the junction...
c:\>junction -d c:\cdrom
What does this have to do with AFS? Not much. The problem is that
Microsoft currently doesn't support "mounting" or "reparsing" with network
connections! Lots of anger here...argggg!
</conspiracy_theory_on>
I have a conspiracy theory that Microsoft doesn't want to support
network mounting simply because it would allow many more apps to be
installed on the network instead of the local drive. Microsoft is "in bed"
with drive manufacturers because they want all their applications to all be
installed locally. This way their applications run much faster than their
competition...aka Unix, because in the enterprise, most Unix admins install
all their apps on the network. It also increases the number of
applications that have to be licensed per-machine, because Microsoft
doesn't support a floating license model. It also allows them to sell
systems management software for managing all those machines with local
applications. Very few applications support the network computing model.
In the old days of DOS/Win31 and Novell, you could install apps on the
network. Over the years the Microsoft Windows cartel has made enterprise
systems management harder and harder because nothing is stored on the
network except maybe user data. This is simply ridiculous and uncalled for.
You think I'm wrong? Then answer me why then doesn't Microsoft allow the
creation of reparse points with the "fsutil" command and not just viewing
them? Why did a third party company have to develop the "junction" command
to make reparse points useful?
</end_conspiracy>
Back to AFS...
The AFS client under Windows is not an installable file system, or IFS,
client. This means that AFS doesn't appear as a real "device" like the C:
drive. That would require a kernel driver. Even if it was based on an IFS
driver it would still appear to application land as another drive
letter. Again, Windows has no other way of dealing with this drive and UNC
issue. At least with an IFS driver you would be able to "mount" or
"reparse" it as "c:\afs".
The AFS client service under windows simply emulates a SMB server so that
you can "net use" to it like any other Microsoft server network
share. This means it is very simple to install as it requires no kernel
pieces and simply runs as a standard Windows service. You "net use" to the
fake server share name, which in most cases is your machine's NETBIOS
hostname with a "-afs" tacked on to the end. So you have something like...
c:\>net use z: \\hostname-afs\all
Since you must tack on the "-afs" part, your hostname will be limited to 9
or so characters. I think the standard hostname character length is
something like 14 characters. In the above case the "all" is a special
share name built into the AFS service signifying the top of the AFS
tree. You don't have to use "all". You can actually specify a sub-path if
you want by creating "sub-mounts" with the AFS client config tool. In this
case you are simply creating share names for the AFS service that point to
deeper directory roots in the AFS tree. For example, if I create a
sub-mount called "test" that points to "/afs/cell/dir1/dir2", then I can
mount "dir2" simply by...
c:\>net use z: \\hostname-afs\test
You don't even need to create sub-mounts if you don't want to. You could
just mount directly as in...
c:\>net use z: \\hostname-afs\all\cell\dir1\dir2"
If you don't want to use drives, then just tell your applications to use
the UNC path as in...
c:\>sort < "\\hostname-afs\all\cell\dir\file" > c:\out.txt
Over the years I have seen many references to Unix people wondering, as you
do, why you can't simply use a UNC path like "\AFS\cell\dir\dir\...". I
believe the effort to so is misplaced. This is like trying to make Windows
work like Unix. What you should do is adjust your thinking to simply use
the "Windows way" until at such time that Windows has the official features
you need built in. You wouldn't have Windows people migrating to Unix and
wanting to use drives and UNC paths under Unix file systems would you?
My reasoning for keeping with the "Windows way" is simply because all the
Windows applications understand it. Introducing a foreign syntax element
into the pathname designations for Windows applications is likely to cause
confusion as well as bugs. Why put yourself through that trouble?
Googling around the net at one time in the past I believe I saw a thread
about some people at MIT (Paul Hill's group?) were working to make the SMB
sharename look something like "\\AFS\cell". I don't know what ever became
of this effort and I don't believe it is worth it in the end.
In my own Windows command shell scripts I simply mount a global drive to
the top of the AFS tree at boot time. This AFS drive is available to all
users, and applications. I also use the "subst.exe" command to create
other drive links to paths down the global drive. For example...
c:\>subst h: n:\uncc\usr\a\trng01\pc
Where H: is the home drive for the user's PC files. I also create an I:
drive which acts as an abstraction, for all our PC based system files and
applications within the AFS tree. This is so that if I move the tree in
AFS in the future to another level in the tree, I just have to re-subst the
I: drive to another path. For example...
c:\>subst i: n:\uncc\coe\ntnet
The I: drive is only mounted when the user's are logged on.
Our global AFS drive is drive N:. My command shell scripts never use the
global AFS drive directly. In all my command shell scripts I use a global
system environment variable instead. For example...
n:\ = AFS filesystem root.
Global system environment variable: NTNET=n:\uncc\coe\ntnet
Always use "%ntnet%\some_path\..." for abstraction.
As to using Unix symbolic links with Windows...
AFS supports Unix (or Posix?) file system symbolic links. This is because
it is based on a Unix file system model. When the AFS client was ported to
Windows there was a problem. Neither Windows FAT, FAT32, nor NTFS support
symbolic links in the traditional sense. Windows NT/2k/XP can "support"
symbolic links under the Posix subsystem layer, but not under the Windows
layer. Windows applications just don't understand what a "symbolic link"
is. So what the AFS developers decided to do was make the symlink look
just like a directory to Windows apps. If you enumerate the AFS tree under
Windows you will encounter symlinks as "real" (to Windows apps)
sub-directories.
You can create an AFS symbolic link using the "symlink" command that ships
with the OpenAFS client. When we create symlinks under Windows we always
specify the path as "/afs/cell/dir/dir/...". In fact, doing it with a
drive:\path won't work. For example...
(n:\ is our AFS filespace here)
n:\cell\dir\>symlink make -name test_link -to /afs/cell/dir/dir
n:\cell\dir\>symlink list test_link
'test_link' is a symlink to '/afs/cell/dir/dir'
n:\cell\dir\>symlink rm test_link
You "can" create a symlink with "drive:\path" for the "-to" argument,
but it won't work. You should use "/afs/cell/dir/dir...". Remember, a
symlink is not a "live" network link of some kind. It is simply a file
stub in AFS that contains a character string that specifies "where" to be
redirected. If you need to convert "drive:\path" to "/afs/cell/path" then
do something like this...
(In this example we might have z:\ mounted to \\machine-afs\all)
c:\>set win_path=z:\cell\dir\dir\file
c:\>set afs_path=/afs/%win_path:~3%
c:\>set afs_path=%afs_path:\=/%
This just strips off the "z:\", and prepends "/afs/", then converts
all the back slashes to forward slashes. So, now the afs_path environment
variable will contain "/afs/cell/dir/dir/file". See help on the command
line "set" command using "set /?" for more information on environment
variable string manipulation.
You can also create symlinks to files the same way.
In summary, what I'm saying here is that there is really no good reason to
force the Unix "/afs/cell/path" model on Windows when the applications
won't use it anyway. I just don't get the need. We've been using the
Windows AFS client since '97 and have never had a problem with this issue,
and we've got around 80 engineering applications installed, some of the
same engineering apps that run on our Solaris machines. For myself, I
would actually prefer the Unix model of everything is a file from the root,
but hey, Windows is Windows because it's Windows. Everybody knows it has
some lame flaws. I've certainly learned to deal with them well over
time. I'm not about to cause myself problems by trying to make my Windows
apps use "/afs" instead of "n:\".
Hope this helped.
Rodney
Rodney M. Dyer
Windows Systems Programmer
Mosaic Computing Group
William States Lee College of Engineering
University of North Carolina at Charlotte
Email: rmdyer@uncc.edu
Web: http://www.coe.uncc.edu/~rmdyer
Phone (704)687-3518
Help Desk Line (704)687-3150
FAX (704)687-2352
Office 267 Smith Building
At 10:49 PM 12/4/2003, you wrote:
>One of the features of AFS is a common global name space. The only
>problem with that is Windows drive mappings don't adhere to the
>/afs/cellname convention for the AFS root.
>
>I have a simple scenario where files can be read via multiple platforms.
>This is problematic for a file where an external file is LINKed to a path
>of Z:/stradamotorsports.com rather than /afs/stradamotorsports.com. A
>windows client will read the linked file fine. A unix client will not
>find the linked file.
>
>The problem gets really sticky with my Solidworks CAD models. The highly
>interrelated models do not respond well to pathnames not being precisely
>correct.
>
>If I can't control the platform or the drive mapping of very computer on
>the planet (I can't, at least as far as Uncle Sam will ever know.:)) then
>I will certainly run into trouble when collaborating with other
>organizations.
>
>Will the windows client ever support global hierarchy that is consistent
>with the conventions of the unix AFS '/afs/cellname' hierarchy?
>
>How have other users managed the disparity between the unix AFS hierarchy
>and the Windows AFS hierarchy? Perhaps the need to access highly
>interrelated files is unique to my situation, but I doubt it.
>
>Later,
>Jason C. Wells
>
>_______________________________________________
>OpenAFS-info mailing list
>OpenAFS-info@openafs.org
>https://lists.openafs.org/mailman/listinfo/openafs-info