X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD
X-Spam-Check-By:	sourceware.org
Message-ID:	<4EA550C7.9080709@lauterbach.com>
Date:	Mon, 24 Oct 2011 13:49:27 +0200
From:	Franz Sirl <Franz DOT Sirl-kernel AT lauterbach DOT com>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: rm -rf cannot delete the upmost directory level anymore on a Novell share
References:	<4E9EFE31 DOT 20809 AT lauterbach DOT com> <20111020092033 DOT GA5988 AT calimero DOT vinschen DOT de> <4EA00B16 DOT 1030400 AT lauterbach DOT com> <20111020130941 DOT GB13505 AT calimero DOT vinschen DOT de> <4EA028C9 DOT 1040300 AT lauterbach DOT com> <20111020172937 DOT GD13505 AT calimero DOT vinschen DOT de> <20111021091056 DOT GH13505 AT calimero DOT vinschen DOT de> <4EA18882 DOT 8040705 AT lauterbach DOT com> <20111021153543 DOT GH2976 AT calimero DOT vinschen DOT de> <4EA539E9 DOT 5080502 AT lauterbach DOT com> <20111024103136 DOT GC14623 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20111024103136.GC14623@calimero.vinschen.de>
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

Am 2011-10-24 12:31, schrieb Corinna Vinschen:
> On Oct 24 12:11, Franz Sirl wrote:
>> Am 2011-10-21 17:35, schrieb Corinna Vinschen:
>>> On Oct 21 16:58, Franz Sirl wrote:
>>>> I will create a support case with Novell. To make my understanding
>>>> clear, I think there are actually 2 problems here (Win32 calls for
>>>> illustration, assuming the directory is already opened):
>>>>
>>>
>>>    0. The directory has been opened with all sharing modes allowed "elsewhere".
>>>
>>>> 1. CreateFile(FILE_READ_ATTRIBUTES | DELETE, FILE_SHARE_DELETE)
>>>> should not succeed, but fail with STATUS_SHARING_VIOLATION
>>>
>>> I didn't see a full strace from W7.  Did you check that this doesn't
>>> happen anyway?
>>
>> strace attached. Succeeding here depends on the access modes of the
>> open handle(s) or if the directory is not open at all.
>
> That's why I added the step 0.  But if the file is open elsewhere,
> this step should not succeed based on the access modes, but only
> based on the sharing modes allowed by the other handle.

Not exactly, at least on W7. For example FILE_SHARE_READ doesn't seem to 
matter without FILE_READ_DATA.

>> Your changes work, I just tried the 20111023 snapshot. See the
>> attached strace on Win7/64.
>
> Thanks, it looks like expected now, given NcFsd's behaviour.  Note
> that this can't be fixed on NWFS.  On NWFS, only the changes to
> upstream coreutils as outlined in
> http://cygwin.com/ml/cygwin/2011-10/msg00481.html will help.

Yes, I noticed that one too, thanks. Any idea when the fix will show up 
in Cygwin's coreutils?


>> I also attached the simple testcase I'll submit to Novell. Please
>> let me know if you think something is wrong with the testcase.
>
> Looks good to me.  For completeness, maybe you should note that
> delete-on-close works in this scenario, but it's desired that both
> methods work, just as on NTFS, for instance.

Good idea, done.

Thanks for your help!
Franz.

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

- Raw text -