[OpenAFS] Status of 1.7 OpenAFS Windows client

Mon, 05 Dec 2011 17:11:22 -0500

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig881D80624CCBC6E01FAE4814
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
    <title></title>
  </head>
  <body bgcolor=3D"#ffffff" text=3D"#000000">
    On 12/5/2011 3:18 PM, Jason Harper wrote:
    <blockquote
cite=3D"mid:277C1701239FAE41850579216CE41D79CF5442B836@EX11.asurite.ad.as=
u.edu"
      type=3D"cite">What about just the dir command? Is it not possible
      for an IFS driver to get something reported as &lt;SYMLINK&gt; or
      &lt;SYMLINKD&gt; by the cmd.exe dir command? So it sounds like MS
      added symlink support only to NTFS, rather than doing it in a
      truly generic way. That stinks.<br>
      <br>
    </blockquote>
    <br>
    The Windows IFS layer supports Reparse Points which are a generic
    structured method of exporting special file types from the file
    system.=C2=A0 An AFS symlink is not the same as an NTFS symlink.=C2=A0=
=C2=A0 You
    are thinking of symlinks as a relative or absolute path in a file
    system with a common root.=C2=A0 That model simply doesn't exist on
    Windows.=C2=A0 File systems are accessed internally via device paths.=
=C2=A0
    NTFS Junctions permit the evaluation of the reparse point to be
    evaluated by NTFS as meaning rewrite the request and push it back on
    the IFS stack for re-evaluation.=C2=A0 For Symlinks, the same is done=
=2E=C2=A0
    However, the representation of a symlink in NTFS is very different
    from a symlink in AFS.=C2=A0 Note that in AFS a Symlink and a Mount P=
oint
    are both stored as symlinks.=C2=A0 The mount point symlink is interpr=
eted
    as a mount point by the cache manager only because the unix mode
    bits on the symlink object are set in a particular way.<br>
    <br>
    I much prefer the Reparse Point approach in which data is structured
    and I don't have be play games to guess how the data should be
    interpreted. <br>
    <br>
    <blockquote
cite=3D"mid:277C1701239FAE41850579216CE41D79CF5442B836@EX11.asurite.ad.as=
u.edu"
      type=3D"cite">
      <pre wrap=3D"">Thanks for your response.

This got me curious how it might work the other way (creating symlinks in=
 afs using windows tools)
</pre>
    </blockquote>
    <br>
    you use the symlink.exe command that ships with AFS and the "fs
    mkmount" command that ships with AFS.<br>
    <br>
    <blockquote
cite=3D"mid:277C1701239FAE41850579216CE41D79CF5442B836@EX11.asurite.ad.as=
u.edu"
      type=3D"cite">
      <pre wrap=3D"">The Windows mklink command just refuses:

Z:\users\j\s\h\jsharper\myafsdir&gt;mklink mymklinklink myrealfile
The file or directory is not a reparse point.
</pre>
    </blockquote>
    <br>
    Of course it refuses.=C2=A0 For starters, AFS assumes that symlinks a=
nd
    mount points are idempotent.=C2=A0 They are defined on creation and
    cannot be altered except to delete them.=C2=A0=C2=A0 The Windows mode=
l is
    create a zero length file or empty directory, set reparse data on
    the object and it is now a reparse point.=C2=A0=C2=A0 Secondly, the F=
SCTL to
    set reparse data is not implemented because AFS does not provide an
    atomic operation that would permit a file or directory to be
    converted to a symlink or mount point.<br>
    <br>
    <blockquote
cite=3D"mid:277C1701239FAE41850579216CE41D79CF5442B836@EX11.asurite.ad.as=
u.edu"
      type=3D"cite">
      <pre wrap=3D"">Interestingly, the Cygwin ln command seems to create=
 something that is understood to be a symlink by Cygwin's ls.exe (but not=
 their find.exe) but in reality appears to actually be a binary file:

</pre>
    </blockquote>
    Sure.=C2=A0 Cygwin has defined a "shortcut" file which is interpreted=
 by
    their tools and only their tools.=C2=A0=C2=A0 It is not a reparse poi=
nt and it
    is not an AFS symlink.<br>
    <br>
    Cygwin can be made to understand OpenAFS mount points and symlinks.=C2=
=A0
    A patch needs to be written and pushed upstream.<br>
    <br>
    I will note that JPSoftware's Take Command shell is OpenAFS aware
    and has been for more than five years.<br>
    <br>
    Jeffrey Altman<br>
    <br>
  </body>
</html>


--------------enig881D80624CCBC6E01FAE4814
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJO3UGMAAoJENxm1CNJffh4od4IALe5I/OCJKUf38TrdavUkQv6
/Fs7Kl4ZWeo9K1Xwn0ERauoP3SFmevresFT4sinRCuHjO3Zwju8a8fgICSu129xZ
+kuLYdVKc7+rFF3LZ20ibRJ26cEv5CUuXCpy2FE3xe3pvAmbql/rlAHl6YOGbqfa
k6IXGzmZiUKDEs2vpsKQujfguI4t+QIidjrTmFOdwiymQrPXtN9DQueInHZGvlIn
jlayUgnf6imzF6gJWd50TEe2z9CYelXU2/1igKWlQuGUK84Bwwj3+10XwKqAaDLn
0eX8Z5SjYhUUzqv63mvsb951rUd2qBOqrWsQI1nCPFhSOXp+yP4LpaYGREz5oFk=
=e4vZ
-----END PGP SIGNATURE-----

--------------enig881D80624CCBC6E01FAE4814--