Re: native symlink

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

On Apr  3 19:29, Corinna Vinschen wrote:
> 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.

I think I know what the problem is here.  Even though Cygwin didn't
recognize the reparse point type and even though it lets the OS handle
the reparse point in subsequent calls, the PC_KEEP_HANDLE flag is not
removed.  The effect is that stat uses the metadata collected in the
symlink_info::check call, which is the reparse point metadata.  So, I
think the right thing to do here is to remove the PC_KEEP_HANDLE flag so
stat reopens the reparse point, but this time without the
FILE_OPEN_REPARSE_POINT flag. 

You're set up to build Cygwin yourself, right?  Can you please try the
below patch?


Thanks,
Corinna


Index: path.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/path.cc,v
retrieving revision 1.672
diff -u -p -r1.672 path.cc
--- path.cc	3 Apr 2013 11:20:36 -0000	1.672
+++ path.cc	3 Apr 2013 20:46:08 -0000
@@ -2668,7 +2668,14 @@ restart:
 		 to the volumes root dir. */
 	      pflags &= ~PC_KEEP_HANDLE;
 	    }
-	  else if (res)
+	  else if (!res)
+	    {
+	      /* Make sure the open handle is not used in later stat calls.
+		 We didn't recognize the reparse point type, so let the
+		 OS handle this the default way. */
+	      pflags &= ~PC_KEEP_HANDLE;
+	    }
+	  else
 	    {
 	      /* A symlink is never a directory. */
 	      conv_hdl.fnoi ()->FileAttributes &= ~FILE_ATTRIBUTE_DIRECTORY;

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