X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 	tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,WEIRD_PORT
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: MVFS results
Date: Thu, 16 Jul 2009 23:13:43 +0000 (UTC)
Lines: 74
Message-ID:  <loom.20090716T225222-72@post.gmane.org>
References:  <loom DOT 20090715T192219-408 AT post DOT gmane DOT org> <20090715204831 DOT GA27613 AT calimero DOT vinschen DOT de> <loom DOT 20090715T213245-387 AT post DOT gmane DOT org> <20090716090703 DOT GH27613 AT calimero DOT vinschen DOT de> <loom DOT 20090716T133741-21 AT post DOT gmane DOT org> <20090716151121 DOT GO27613 AT calimero DOT vinschen DOT de> <loom DOT 20090716T154525-611 AT post DOT gmane DOT org> <20090716165112 DOT GS27613 AT calimero DOT vinschen DOT de> <loom DOT 20090716T165527-559 AT post DOT gmane DOT org> <20090716174525 DOT GT27613 AT calimero DOT vinschen DOT de>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

> Oh well.  Ok, I planned to check this change in and let you then test
> from CVS.  But since that's a problem for you, here's the patch.  The
> important part is that Cygwin should now always create symlinks as
> shortcuts on MVFS, regardless of the CYGWIN=winsymlink setting.  Please
> check.

Not quite.  I've finally got my tree in the state where I could apply this 
patch.  For the record (more documenting it for myself, than anything else), I 
used setup.exe to get 1.7.0-51 sources, used 'git init && git add . && git 
commit -m 1.7.0-51' to make it easier to track commits, then ran these commands 
to grab all CVS changes since that point:

$ wget http://cygwin.com/ml/cygwin-cvs/2009-q3/msg0003{0,1,2,3,4,5,6,7,8}.html

$ for f in msg*.html; do
 sed -n 's,.*\(http://sources.redhat.com/cgi-bin[^<]*\)<.*,\1,
   s,&amp;,\&,gp' $f > ${f%.html}.txt;
done

$ for f in msg0003*; do
 while read file; do
   wget -O patch.txt "$file"; patch -p2 < patch.txt;
 done < $f ; git commit -a -m "fold in $f";
done


But in running the build, I noticed:

1403      mk_winsym |= win32_newpath.fs_is_mvfs ();
(gdb) s
path_conv::fs_is_mvfs (this=0x2247ec) at ../../../../winsup/cygwin/path.h:234
234       bool fs_is_mvfs () const {return fs.is_mvfs ();}
(gdb) p fs
$2 = {status = {flags = 3, samba_version = 0, name_len = 255, 
    is_remote_drive = 1, has_acls = 0, hasgood_inode = 0, caseinsensitive = 0, 
    {{is_fat = 0, is_ntfs = 0, is_samba = 0, is_nfs = 0, is_netapp = 0, 
        is_cdrom = 0, is_udf = 0, is_csc_cache = 0, is_sunwnfs = 0, 
        is_unixfs = 0, is_mvfs = 0}, fs_flags = 0}}, sernum = 36984713}

So the is_mvfs flag is not getting set, and symlinks are still being botched 
with an attempt to use the unavailable system flag.

Further debugging:

Breakpoint 1, fs_info::update (this=0x224bd8, upath=0x223970, in_vol=0x6b0)
    at ../../../../winsup/cygwin/mount.cc:192
192        name_len (ffai_buf.ffai.MaximumComponentNameLength);
...
233           if (!got_fs ()
(gdb) p fsname
$3 = {Length = 10, MaximumLength = 10, Buffer = 0x2233dc}
(gdb) p ro_u_mvfs
$4 = {Length = 8, MaximumLength = 10, Buffer = 0x611cad30}
(gdb) x/10c fsname.Buffer
0x2233dc:       77 'M'  0 '\0'  86 'V'  0 '\0'  70 'F'  0 '\0'  83 'S'  0 '\0'
0x2233e4:       0 '\0'  0 '\0'
(gdb) x/10c ro_u_mvfs.Buffer
0x611cad30 <ro_u_fat+8>:        77 'M'  0 '\0'  86 'V'  0 '\0'  70 'F'  0 '\0' 
83 'S'   0 '\0'
0x611cad38 <ro_u_fat+16>:       0 '\0'  0 '\0'
(gdb) n
252             is_sunwnfs (RtlEqualUnicodeString (&fsname, &ro_u_sunwnfs, 
FALSE));


Does the fact that MVFS is including the trailing NUL in fsname.Length, but 
ro_u_mvfs is not, relevant to RtlEqualUnicodeString returning false, even 
though the two Buffers are identical over their MaximumLength?

-- 
Eric Blake



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple