From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4455 invoked by alias); 20 Oct 2011 09:21:19 -0000 Received: (qmail 4308 invoked by uid 22791); 20 Oct 2011 09:20:55 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Thu, 20 Oct 2011 09:20:37 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id B63602CBDA0; Thu, 20 Oct 2011 11:20:33 +0200 (CEST) Date: Thu, 20 Oct 2011 09:21:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: rm -rf cannot delete the upmost directory level anymore on a Novell share Message-ID: <20111020092033.GA5988@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <4E9EE8CC.5090806@lauterbach.com> <20111019154540.GE22809@calimero.vinschen.de> <4E9EFE31.20809@lauterbach.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4E9EFE31.20809@lauterbach.com> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-10/txt/msg00386.txt.bz2 On Oct 19 18:43, Franz Sirl wrote: > Am 2011-10-19 17:45, schrieb Corinna Vinschen: > >On Oct 19 17:12, Franz Sirl wrote: > >>sometime between coreutils-7.0 and coreutils-8.4 (sorry, I don't > >>have any other in between versions anymore) this simple command > >>started to fail: > >> > >># mkdir -p lev1/lev2/lev3 > >># rm -rfv lev1 > >>removed directory: `lev1/lev2/lev3' > >>removed directory: `lev1/lev2' > >>rm: cannot remove `lev1': Device or resource busy > >> > >>Tested with coreutils-8.10 and cygwin1.dll from the 20111017 > >>snapshot, as the cygwin1.dll didn't make any difference for the > >>problem. > >> > >>If I just use rm.exe from coreutils-7.0 everything starts to work as > >>expected again: > >> > >># mkdir -p lev1/lev2/lev3 > >># rm -rfv lev1 > >>removed directory: `lev1/lev2/lev3' > >>removed directory: `lev1/lev2' > >>removed directory: `lev1' > > > >The problem is, it works fine on local and remote NTFS, as well as on > >Samba. Since the number of open handles doesn't depend on the underlying > >filesystem, why should it fail for NWFS? > > True. But on the other hand NWFS and NcFsd exercise a lot of pathes > in the Cygwin sourcecode that aren't usually used. Not really a lot. NWFS is known to have three problems: - The NtQueryInformationFile(FileBasicInformation) call fails. This call is only used in circumstance which don't affect NWFS. - NWFS only supports filenames which follow DOS conventions. That is, it does not support filenames with leading spaces or trailing dots and spaces. This is only checked for when generating filenames. - NWFS does not support re-opening a file by handle, so it always has to be re-opened by name. The only difference here is how the OBJECT_ATTRIBUTES is created, with a handle or with a name. > Even between NWFS > on XP and NcFsd on Win7 there are differences, because fs.is_nwfs() > doesn't trigger on Win7 with the Novell Client (the filesystem name > is different). I don't have access to the various filesystems, so I depend on users giving me the required information about exotic filesystems if they wish that it will be supported. For "NcFsd", can you please post the output of the `/usr/lib/csih/getVolInfo ' command? Also, if you haven't already done so, plase create a Cygwin mount point pointing to some path on the filesystems and paste the output of the command `mount'. This shows under which filesystem NcFsd is subsumed right now. > >> 216 174576 [main] rm-8.10 336 unlink_nt: Opening file for delete > >>failed, status = 0xC0000043 > >> 240 174816 [main] rm-8.10 336 seterrno_from_nt_status: /netrel/src/cygwin-snapshot-20111017-1/winsup/cygwin/fhandler_disk_file.cc:1735 > >>status 0xC0000043 -> windows error 32 > > > >That's a sharing violation. Where's the difference to the strace > >output with the exact same Cygwin DLL and rm from coreutils 7? > > Hmm, I just see that on Win7 the errorcode for unlink_nt is > different, for completeness: > > 2046 158907 [main] rm-8.10 2940 unlink_nt: Setting delete > disposition failed, status = 0xC0000121 > 594 159501 [main] rm-8.10 2940 seterrno_from_nt_status: /netrel/src/cygwin-snapshot-20111017-1/winsup/cygwin/fhandler_disk_file.cc:1735 > status 0xC0000121 -> windows error 5 > 193 159694 [main] rm-8.10 2940 geterrno_from_win_error: windows > error 5 == errno 13 The OS returns STATUS_CANNOT_DELETE here. Which is very helpful, of course, since it does nothing to tell the developer *why* it can't be deleted. If we could recognize NcFsd (see my requests above), what we could do at this point is to try "delete-on-close". The code for that exists in unlink_nt and it's used exactly in the case where we get the error code STATUS_CANNOT_DELETE. However, due to a problem with remote shares in this context, Cygwin only tries that with local filesystems right now. > The strace from rm-7.0 on XP looks like this: > [...] > So with rm-7.0 it doesn't try to use unlink_nt() and also rm-8.10 > doesn't try to use unlink_nt() on a samba-3.4.3 share. That's why it > looked a bit suspicious to me. You misinterpreted the strace output. unlink_nt only generates strace output if something has gone wrong. It's called, it just doesn't print anything in case of success. Hmm, puzzeling. So when you use the NcFsd driver you can open the file but trying to set the delete dispostion fails with STATUS_CANNOT_DELETE, and if you're accessing it via SMB and so is recognized as NWFS, the open for delete already fails with a STATUS_ACCESS_VIOLATION. In theory, the STATUS_ACCESS_VIOLATION should not be Cygwin, and not rm itself. In the strace output from rm 7.0 you'll see this: fhandler_base::open: 0 = NtCreateFile (0x704, 80100000, \??\J:\FRA\test_rm_rf\lev1, io, NULL, 0, 7, 1, 4020, NULL, 0) [...] open: 3 = open (/test_rm_rf/lev1/lev2/.., 0x8000) [...] rmdir: 0 = rmdir (/test_rm_rf/lev1) Note the absence of a "close (3)" here. So rm has an open file descriptor to /test_rm_rf/lev1, but the rmdir succeeds. That's how it should be, in fact. Cygwin opens files always with all sharing flags set, so a file opened by a Cygwin process should not result in a sharing violation in another open call. The exception is the first NtOpenFile in unlink_nt, which opens the file with FILE_SHARE_DELETE only to find out if the file has an open handle somewhere else. In that case it gets a STATUS_SHARING_VIOLATION, the next NtOpenFile will open the file with all sharing flags set, and unlink_nt will try to delete the file or to rename it, or to move it to the recycle bin, dependent on its path. Anyway, we're not a single step further. First of all, please send the FS information I requested above. Next, please generate straces of rm 7.0 and rm 8.4 for this scenario, both on the same machine and running the latest Cygwin developer snapshot and send the full straces here. 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