This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MVFS results


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]