On 4/20/2011 9:13 AM, Axel Müller wrote:
> Any new info on this topic? Anything I can do to debug it? I would appreciate
> any help.
>
> Axel
The troubleshooting section of the release notes installed on the client
machine (Programs->OpenAFS->Documentation->Release Notes) explains how
to colle
> > If the symlink is being listed as a file when it is a directory, it is
> > because the target path of the symlink cannot be evaluated in the
> > current context. Since the target of the link cannot be accessed, the
> > AFS cache manager has no knowledge of whether it is a directory or a
> > fi
> > The difference to a "normal" directory is the FileAttribute returned by
> QueryBasicInformationFile.
> > For the symlink it is "N" and for a "normal" directory it is "D". I guess
> that's why the ls fails.
>
> If the symlink is being listed as a file when it is a directory, it is
> because t
On 4/13/2011 5:40 AM, Axel Müller wrote:
> The difference to a "normal" directory is the FileAttribute returned by
> QueryBasicInformationFile.
> For the symlink it is "N" and for a "normal" directory it is "D". I guess
> that's why the ls fails.
If the symlink is being listed as a file when it
-Ursprüngliche Nachricht-
> Whatever the failure is, it is not because of how the symlink is
> created. Determine which Win32 File Operation is failing using Process
> Monitor and discuss that. The fact that the object is a symlink is a
> red-herring.
OK. The failure does not depend how t
