X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Thu, 16 Jul 2009 11:07:03 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: MVFS results
Message-ID: <20090716090703.GH27613@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <loom.20090715T213245-387@post.gmane.org>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

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