X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Fri, 21 Oct 2011 17:35:43 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: rm -rf cannot delete the upmost directory level anymore on a Novell share
Message-ID: <20111021153543.GH2976@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4E9EE8CC DOT 5090806 AT lauterbach DOT com> <20111019154540 DOT GE22809 AT calimero DOT vinschen DOT de> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4EA18882.8040705@lauterbach.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 Oct 21 16:58, Franz Sirl wrote:
> Am 2011-10-21 11:10, schrieb Corinna Vinschen:
> >>It might be worth a try to ask the Novell support why this occurs.
> >>This is a bug, IMHO.  Since Vista, this call should even be supported
> >>in the Win32 API, using the call
> >>
> >>   FILE_BASIC_INFO fbi;
> >>   GetFileInformationByHandleEx (fhdl, FileBasicInfo,&fbi, sizeof fbi);
> 
> This succeeds?? Arrgh, looking at my testcase again, I see that I
> only used NtOpenFile(WRITE_ATTRIBUTES | DELETE). I reused my code to
> test the read-only file deletion, but forgot to change this, sorry.
> As soon as I added READ_ATTRIBUTES, the testcase using
> NtQueryInformationFile(FileBasicInformation) succeeded.

Ok, I change that in Cygwin for completeness.  It's still not used,
but it's good to know.

> >But there's one more change:  As you observed, NcFsd does not return a
> >STATUS_SHARING_VIOLATION when trying to open the top level directory for
> >DELETE, rather trying to set the delete disposition fails with
> >STATUS_CANNOT_DELETE.  When this error occurs, unlink_nt now also checks
> >for NcFsd, and if so, it tries delete-on-close as another method to
> >delete the file/directory.
> >
> >This is just an experiment, so could you please take this snapshot and
> >test your fine testcase under strace on W7/NcFsd and send the strace here?
> 
> The functionality works (directory is deleted), but an error is
> reported anyway:
> 
> rm-8.4: cannot remove `lev1': Directory not empty
> 
> The corresponding strace looks like:
> [...]
>  1754  244698 [main] rm-8.4 6088 seterrno_from_nt_status: /ext/build/netrel/src/cygwin-snapshot-20111021-1/winsup/cygwin/fhandler_disk_file.cc:1735
> status 0xC0000101 -> windows error 145

Ouch, yes, that makes sense.  The test for success should only be
performed for samba shares.  I'll fix that.

> >However,  IMHO this is a bug in NcFsd, just like the sharing violation
> >in NWFS.  Since NcFsd is activaly maintained, it might make sense for
> >you or any other NcFsd user to open a support case for this problem
> 
> 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?

> 2. CreateFile(FILE_READ_ATTRIBUTES | DELETE, FILE_SHARE_READ |
> FILE_SHARE_WRITE | FILE_SHARE_DELETE) should succeed and the

... and that therefore this second NtCreateFile works as expected?

> following SetFileInformationByHandle(DELETE) should succeed too

Yes.  It should not be required to open the dir with delete-on-close,
just because it's still open elsewhere.  After all, the meaning of
"setting the delete disposition" is not that the dir has to be deleted
immediately if it's still in use.

> This is what I came up with after looking what happens against a
> samba-3.4.3 and WinXP share. Does that sound right?

More or less, yes.  I'll check in my changes shortly.


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