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


On Jul 15 22:03, Eric Blake wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > 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

MVFS reports to have no ACLs so chmod behaves like on FAT.  It just
sets or resets the DOS R/O attribute.  From our client perspective,
it doesn't matter how it's implemented.

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

Ultimately the work is done in fhandler_base::utimens_fs() in both
cases.

> > 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:
> [...]
> 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:

Hmm.

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

STATUS_ACCESS_DENIED.  But why?

> (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?

Not exactly.  If I had MVFS here, I'd try various changes to the
arguments to NtOpenFile which make sort of sense.

For instance, maybe it chokes on the sharing flags.  I'd try with
FILE_SHARE_VALID_FLAGS instead of just FILE_SHARE_DELETE.

Btw., it's very helpful to observe what happens exactly using
sysinternal's procmon.

How do I get MVFS on my system for testing?


Corinna

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

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