[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
a.mueller@procitec.de
Wed, 13 Apr 2011 14:07:41 +0200
> > 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