[OpenAFS] =?UTF-8?Q?Re=3A_=5BOpenAFS=5D_Re=3A_=5BOpenAFS=5D_Re=3A_=5BOpenAFS=5D_A?= =?UTF-8?Q?W=3A_Re=3A_=5BOpenAFS=5D_Windows=0A_client_Cygwin_and_symlink?= =?UTF-8?Q?s_on_afs_volume?=

[Axel Müller]

> > 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 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
> file and must guess.
I don't understand. Why can the target path of the symlink not be evaluated?
Here is the ls output from Linux
drwxr-xr-x   2   30 amueller    4096 2011-04-11 11:32 bin
lrwxr-xr-x   1   30 amueller       3 2011-04-13 10:49 link_to_bin -> bin

Windows Explorer can resolve link_to_bin as a directory (it shows the folder icon and I can open it as a directory).

ls from Cygwin shows
drwxr-xr-x   2   30 amueller    4096 2011-04-11 11:32 bin
drwxr-xr-x   1   30 amueller       3 2011-04-13 10:49 link_to_bin -> bin

Then I updated Cygwin. And now it shows
drwxr-xr-x   2   30 amueller    4096 2011-04-11 11:32 bin
-rwxr-xr-x   1   30 amueller       3 2011-04-13 10:49 link_to_bin -> bin

link_to_bin is indeed shown as a file.

So do you think this is a bug in Cygwin? But why did it work in your example?

  Axel