Re: native symlink

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Apr  3 12:52, Jeffrey Altman wrote:
> On 4/3/2013 11:29 AM, Corinna Vinschen wrote:
> > You never explained why this happens and at which point in the code.  So
> > far it was the right thing to do, and I'm pretty sure you know why.  I
> > don't change that, unless you can show me where and when this leads to
> > wrong behaviour.  I asked for these details but you didn't offer an
> > explanation besides the fact itself so far.  And it would have been
> > no problem to add a special handling for AFS in the cases where it went
> > wrong.  I guess this is kind of a moot point, now that you converted
> > to native symlinks, but this had to be said.
> 
> I highlighted the bad section of code in the patch Christopher commented
> on.  The code in question is:
> 
> path.cc symlink_info::check_reparse_point() final else block.
> 
> /* Maybe it's a reparse point, but it's certainly not one we recognize.
>    Drop REPARSE attribute so we don't try to use the flag accidentally.
>    It's just some arbitrary file or directory for us. */
> 
>    fileattr &= ~FILE_ATTRIBUTE_REPARSE_POINT;
>
> As a result of this change, the timestamps and size of the reparse point
> are reported to the application instead of the reparse point target's
> stat information.

No, no, no.  Removing FILE_ATTRIBUTE_REPARSE_POINT is done for
non-symlink reparse points only.  Removing this flag makes sense,
because it avoids the usage of FILE_OPEN_REPARSE_POINT in later
NtCreateFile/NtOpenFile calls.

This is definitely not the culprit why stat information for the reparse
point target is wrong, since that's exactly what's supposed to happen.
Something else is amiss in this situation, but right now, debugging
emacs (*shudder*), I don't see what it is.

> > - The inability of normal users to create symlinks by default.
> > 
> >     This can be worked around by changing the policy, but it's still a
> >     PITA.  Normal users don't know about the policy, some of them don't
> >     even have the "Local Security Policy" MMC snap in.  Even in a
> >     corporate environment it requires to change the policy settings and
> >     we all know how admins don't like to *soften* a policy.  But let's
> >     say we can help along with a FAQ entry.
> 
> Working around the policy by issuing DeviceIoControl() operations is
> possible but will open another can of worms.  I do not believe that
> Cygwin should provide a backdoor.

DeviceIoControl is no backdoor.  It still imposes kernel restrictions.
And it's how CreateSymbolicLink is implemented under the hood anyway
(or rather: NtFsControlFile).  We're not using W32api functions for
file access.

> > - Native symlinks are marked as file or directory.
> > 
> >     This has been added clearly for the benefit of Windows Explorer.
> >     But it's a PITA as well because it destroys interoperability.  It's
> >     common that POSIX symlinks are created before the target exists.
> >     How on earth should the symlink(2) function know if the target is
> >     supposed to be a dir or a file.  But Explorer as well as CMD will do
> >     the wrong thing if the symlink is using a non-matching dir/file
> >     marker.
> 
> The target of the symlink must be resolved and the
> FILE_ATTRIBUTE_DIRECTORY flag set appropriately for all
> GetFileAttribute[Ex] and Find*File[Ex] operation responses.  It is the
> inclusion of stat information in the directory enumeration output which
> mandates this behavior.
> 
> Given the inclusion of stat information and the fact that reparse points
> can refer to objects that have a very high latency to access, it is a
> reasonable design choice to require the reparse point expose the
> FILE_ATTRIBUTE_DIRECTORY bit that the target will have.

It's non-POSIXy.  That's my point of view in the first place and
that's what we're discussing here.

> >     But we could store the POSIX path with backslashes, thus working
> >     around the issue, no?  No.  An absolute path starting with a
> >     backslash is possible, but the Windows tools will evaluate it as
> >     root-relative to the current drive.  cd to another drive in cmd,
> >     and interop is broken again.
> 
> It took me a long time to understand how these fields are used.  The
> field names were poorly chosen.
> [...]
> Does this help?

Well, not really since it's nothing new.  I guess we should stop trying
to educate each other.  We all had our share of debugging how native
symlinks work, apparently.

> An environment variable should address James' use case.  For creating
> Symlinks in AFS a test for File System name "AFSRDRFsd" in the volume
> information can be used as an indicator that DOS SYSTEM attribute is not
> supported.

http://cygwin.com/acronyms/#PTC

An addition to the fs_info class, the fs_names array, and the
fs_info::update function would be fine (post-1.7.18).


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat