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:

> Eric, can you please change syscalls.cc, line 532 from
> 
>   NtSetAttributesFile (fh, pc.file_attributes () & ~FILE_ATTRIBUTE_READONLY);
> 
> to
> 
>   {
>     status = NtSetAttributesFile (fh, pc.file_attributes () & 
~FILE_ATTRIBUTE_READONLY);
>     if (!NT_SUCCESS (status))
>       system_printf ("Blah: %p", status);
>   }
> 
> and see what status code is returned?  Hmm, it's possible that
> it doesn't print anything because it doesn't even reach this code.

By itself, the Blah is never printed.

> > Just as we suspected, MVFS doesn't support DOS attributes, which also 
> > interferes with deletion abilities (I can also use 'chmod a+w' instead 
> > of 'attrib -r' to get deletion to work).
> 
> This is really weird.  The R/O flag *is* supported, the SYSTEM flag
> isn't.  I assume the HIDDEN flag isn't either, but that's a minor
> problem.

You are correct, 'attrib +h' has no effect.  I also suspect that the R/O flag 
is being faked based on write permissions.  That is, I can do:

$ attrib foo
        M:\foo
$ chmod a-w foo
$ attrib foo
    R   M:\foo

> 
> As I said above, I assume that MVFS has a problem similar to what we
> have for remote HPFS.  It's not sufficient to set only the minimal
> set of access flags in calls to NtCreateFile/NtOpenFile in some
> circumstances.  I can't tell where the problem is for cp -p since that
> shouldn't call anything different from touch in terms of setting timestamps.

utimensat vs utimens?

> 
> However, for the delete case I have a hunch that changing syscalls.cc,
> line 457 from
> 
>   access |= FILE_WRITE_ATTRIBUTES;
> 
> to
> 
>   access |= GENERIC_WRITE;

Even with this added to the patch, it still doesn't seem to help.  But 
something weird is certainly going on:

Breakpoint 1, unlink_nt (pc=@0x2247f4)
    at ../../../../winsup/cygwin/syscalls.cc:445
445     unlink_nt (path_conv &pc)
(gdb) n
452       ACCESS_MASK access = DELETE;
(gdb) 
456       if (pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
(gdb) 
457         access |= GENERIC_WRITE;
(gdb) 
459       ULONG flags = FILE_OPEN_FOR_BACKUP_INTENT;
(gdb) 
462       if (pc.is_rep_symlink ())
(gdb) 
465       pc.get_object_attr (attr, sec_none_nih);
(gdb) 
472       bin_status bin_stat = dont_move;
(gdb) 
473       status = NtOpenFile (&fh, access, &attr, &io, FILE_SHARE_DELETE, 
flags);
(gdb) p fh
$1 = (HANDLE) 0x2247f4
(gdb) p access
$2 = 1073807360
(gdb) p attr
$3 = {Length = 24, RootDirectory = 0x0, ObjectName = 0x224814, Attributes = 0, 
  SecurityDescriptor = 0x0, SecurityQualityOfService = 0x0}
(gdb) p io
$4 = {Status = 0, Information = 0}
(gdb) p flags
$5 = 16384
(gdb) s
/home/eblake/coreutils/src/rm: cannot remove `foo': Permission denied

Program exited with code 01.

Basically, the NtOpenFile took over execution (I'm guessing that it triggered a 
fault handler, which interfered with single stepping?).  My next attempt:

(gdb) b 641
Breakpoint 2 at 0x610e2e3c: file ../../../../winsup/cygwin/syscalls.cc, line 
641.
Breakpoint 2, unlink (
    ourname=0x6b0038 "/project/fabt/foo") 
at ../../../../winsup/cygwin/syscalls.cc:641
641       if (NT_SUCCESS (status))
(gdb) p/x status
$7 = 0xc0000022
(gdb) n
644         __seterrno_from_nt_status (status);
(gdb) 
/home/eblake/coreutils/src/rm: cannot remove `foo': Permission denied

Program exited with code 01.

Now, even __seterrno_from_nt_status is running away.


Any ideas on what I should try next?

-- 
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]