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 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: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , 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