X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Tue, 14 Sep 2010 19:07:53 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Deletion race in NtSetFileInformation ? (Directory not empty error in rm -r -f) Message-ID: <20100914170753.GI15121@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20100914083821 DOT GF16534 AT calimero DOT vinschen DOT de> <4C8FA533 DOT 10306 AT ixiacom DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4C8FA533.10306@ixiacom.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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 Sep 14 09:39, Earl Chew wrote: > > There shouldn't be any race. When you set the delete disposition, > > the file is actually deleted as soon as the last handle to the file > > is closed. If the file isn't opened by another process, it will > > disappear right at the NtClose at the end of unlink_nt. Please note > > that the call to check_dir_not_empty already takes place *only* if > > trying to open the directory failed with STATUS_SHARING_VIOLATION. > > So there *was* another process blocking things. > > Corinna, > > Yes, I noticed that check wrt STATUS_SHARING_VIOLATION. > > These actions are performed consequential to a shell script, > that launches a Makefile, that performs the rm -r -f ... so within > that context there is definitely scope for oversight and we > might inadvertently have a process getting in the way. > > When you describe the other process blocking things, what might > that other process be doing? > > I presume that other process having the directory in question > open, or as cwd is sufficient. ...or having a cwd below the directory. Trying to remove a directory which is the CWD of some process is the most common reason that the directory is blocked, because the Win32 CWD is opened without the FILE_SHARE_DELETE flag. Especially something like `rm -rf ../foo' is suspicious, if foo is the CWD of the current shell. We're trying to revert this to the Linux way again in 1.7.8 (see the thread starting at http://cygwin.com/ml/cygwin/2010-09/msg00342.html), but even after that the problem remains for any non-Cygwin process. > Is there anything else I should be on the lookout for? Virus scanners, etc. There *might* be some unfortunate interaction with a scanner which keeps handles of just deleted files or dirs open. 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