pseudo-symlinks on directories

[Steve French]

There is a file type similar in some ways to symlinks, called junctions
(For NTFS and CIFS they are a form of "reparse point") that is supported
in CIFS and which a few filesystems have to deal with.   The only valid
case I have seen is that in which directories (rather than files) are
marked as reparse points but that leads to the question -

Should junctions (reparse points) be treated as symlinks or as
directories?

Linux's NTFS filesystem seems to ignore the flag and treat them as
directories.  I had been treating them in the cifs filesystem as a
symlink (although temporarily I do not support readlink on them) but the
path that they return typically has what Linux what consider an invalid
server local absolute path (e.g. "c:\target_dir") which follow_link
would not be able to handle.   If I ignore the reparse flag and treat
them as directories (as NTFS does) rather than symlinks, they would look
much like a hardlinked directory (if that were legal) but with different
inode numbers on source and target.  If I treat it as a symlink then I
would need to go through hoops in cifs_readlink and cifs_followlink to
be able to return the proper information in "ls -l" and similar commands
but still allow cd to the directory to work.   

There is a small amount of useful information that an application has
when it knows that a directory is symlinked, even though the path can
not be followed rationally on the client, but I think that it is not
enough to make it worth while to continue to treat as symlinks.

My gut reaction is to follow a recent patch suggestion and change cifs
client to treat these junctions/reparse points as directories (which is
a trivial change to the cifs vfs code), perhaps with a fake xattr for
the inode that gives the reparse info.