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
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 16:25:49 +0000 (UTC)
Lines: 54
Message-ID:  <loom.20090716T154525-611@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>
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:

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

Nope, still chokes on FILE_SHARE_VALID_FLAGS with access denied.

> Another idea would be that the MVFS driver refuses the open request for
> DELETE *because* the R/O flag is set.  That's wrong behaviour but it is
> as it is.  If I'm right, you would have to open the file with
> FILE_WRITE_ATTRIBUTES permission only, remove the R/O flag, re-open the
> file with DELETE access, close the original handle, and then go ahead
> with the default unlink procedure, along these lines (tested on FAT):
> 

Definite improvement.  I'm now able to delete read-only files on MVFS when they 
are not held open by any process.  I don't know if this rearrangement has any 
speed penalties for other filesystems that don't have this problem, or if you 
might want to make the path taken conditional on the file system type.

There are still issues trying to delete open files, where readdir() and stat() 
still see the file after it has been deleted, but utimes() and open() fail 
because it has been marked for deletion.  Do you need an strace() of the rm and 
what it attempted with the recycle bin?  At any rate, as soon as the last 
handle is closed, then the readdir() and stat() no longer see the file.  Maybe 
for MVFS it would be better to return EBUSY instead of letting unlink succeed 
when the handle is still open by another process:

$ touch foo
$ chmod a-w foo
$ exec 5<foo
$ rm foo
rm: remove write-protected regular empty file `foo'? y
$ stat foo
  File: `foo'
  Size: 0               Blocks: 0          IO Block: 65536  regular empty file
Device: 2345789h/36984713d      Inode: 6687745983824360078  Links: 1
Access: (0444/-r--r--r--)  Uid: (22382/  eblake)   Gid: (10513/Domain Users)
Access: 2009-07-16 10:14:51.000000000 -0600
Modify: 2009-07-16 10:14:51.000000000 -0600
Change: 2009-07-16 10:15:05.000000000 -0600
$ touch foo
touch: cannot touch `foo': Permission denied
$ exec 6<bar
bash: bar: Permission denied
$ exec 5<&-
$ stat foo
stat: cannot stat `foo': No such file or directory

What do you want me to help tackle 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