[OpenAFS] Status of 1.7 OpenAFS Windows client

Jeffrey Altman jaltman@your-file-system.com
Mon, 05 Dec 2011 17:11:22 -0500

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
  <body bgcolor=3D"#ffffff" text=3D"#000000">
    On 12/5/2011 3:18 PM, Jason Harper wrote:
      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>
    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.=
    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=
    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=
    are both stored as symlinks.=C2=A0 The mount point symlink is interpr=
    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>
    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>
      <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)
    you use the symlink.exe command that ships with AFS and the "fs
    mkmount" command that ships with AFS.<br>
      <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.
    Of course it refuses.=C2=A0 For starters, AFS assumes that symlinks a=
    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=
    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>
      <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:

    Sure.=C2=A0 Cygwin has defined a "shortcut" file which is interpreted=
    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>
    Cygwin can be made to understand OpenAFS mount points and symlinks.=C2=
    A patch needs to be written and pushed upstream.<br>
    I will note that JPSoftware's Take Command shell is OpenAFS aware
    and has been for more than five years.<br>
    Jeffrey Altman<br>

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

Version: GnuPG v1.4.9 (MingW32)