On 12/5/2011 3:18 PM, Jason Harper wrote:
What about just the dir command? Is it not possible for an IFS driver to get something reported as <SYMLINK> or <SYMLINKD> 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. The Windows IFS layer supports Reparse Points which are a generic structured method of exporting special file types from the file system. An AFS symlink is not the same as an NTFS symlink. You are thinking of symlinks as a relative or absolute path in a file system with a common root. That model simply doesn't exist on Windows. 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. For Symlinks, the same is done. However, the representation of a symlink in NTFS is very different from a symlink in AFS. Note that in AFS a Symlink and a Mount Point are both stored as symlinks. The mount point symlink is interpreted as a mount point by the cache manager only because the unix mode bits on the symlink object are set in a particular way. 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. 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. The Windows mklink command just refuses:Z:\users\j\s\h\jsharper\myafsdir>mklink mymklinklink myrealfile The file or directory is not a reparse point. Of course it refuses. For starters, AFS assumes that symlinks and mount points are idempotent. They are defined on creation and cannot be altered except to delete them. The Windows model is create a zero length file or empty directory, set reparse data on the object and it is now a reparse point. Secondly, the FSCTL 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. Sure. Cygwin has defined a "shortcut" file which is interpreted by their tools and only their tools. It is not a reparse point and it is not an AFS symlink.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: Cygwin can be made to understand OpenAFS mount points and symlinks. A patch needs to be written and pushed upstream. I will note that JPSoftware's Take Command shell is OpenAFS aware and has been for more than five years. Jeffrey Altman |
signature.asc
Description: OpenPGP digital signature
