From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28264 invoked by alias); 25 Apr 2014 14:23:57 -0000 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 Received: (qmail 28247 invoked by uid 89); 25 Apr 2014 14:23:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: server.obj-sys.com Received: from server.obj-sys.com (HELO server.obj-sys.com) (74.50.121.244) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 25 Apr 2014 14:23:54 +0000 Received: from 75-147-126-222-philadelphia.hfc.comcastbusiness.net ([75.147.126.222]:51663 helo=[10.0.0.202]) by server.obj-sys.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wdh2e-0001dS-Rs for cygwin@cygwin.com; Fri, 25 Apr 2014 10:23:52 -0400 Message-ID: <535A6FF9.90004@obj-sys.com> Date: Fri, 25 Apr 2014 14:23:00 -0000 From: Douglas Coup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: rm -f behavior References: <5358260B.90807@obj-sys.com> <20140424142304.GT2339@calimero.vinschen.de> <53592F15.4040309@obj-sys.com> <20140424163624.GU2339@calimero.vinschen.de> <20140425121614.GB5666@calimero.vinschen.de> In-Reply-To: <20140425121614.GB5666@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Get-Message-Sender-Via: server.obj-sys.com: authenticated_id: dcoup@obj-sys.com X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00568.txt.bz2 Objective Systems, Inc. REAL WORLD ASN.1 AND XML SOLUTIONS Tel: +1 (484) 875-9841 Fax: +1 (484) 875-9830 Toll-free: (877) 307-6855 (USA only) http://www.obj-sys.com On 4/25/2014 8:16 AM, Corinna Vinschen wrote: > On Apr 24 18:36, Corinna Vinschen wrote: >> On Apr 24 11:34, Douglas Coup wrote: >>> If I do "which rm" and "which chmod", it shows that both commands >>> resolve to the Cygwin binaries. >>> >>> The attached rm.notworking.trace file is from an "rm -f dac.txt" >>> command that gets the permission denied error; i.e., when the >>> permissions on the file are 444. Things seem to start going south >>> at entry 34276. >> Gosh, how many ways to fail does transactional NTFS know? > Btw., this is not just the result of creating the file and chmod'ing it > to 444 in Cygwin, is it? The reason I'm asking is that Cygwin does not > set the DOS R/O bit when chmod'ing the file to 444. In fact, Cygwin > never sets the R/O bit, except for *.lnk type symlinks. It doesn't seem to be related specifically to the chmod command. For example, we use Perforce as our software control system. The files in my Perforce workspaces that are under Perforce control are read-only files unless they're checked out for modification. In Cygwin this means the files have a permission mask of 444 out of the box; no chmod command was done. If I pick one of those files and try to do an rm -f on it, I get the permission denied error. If I copy the file to a different name, I also get the permission denied error if I try to do an rm -f on it. But if I do chmod u+w on the file, I can do the rm -f. > > However, this: > >>> 20 34002 [main] rm 7580 unlink_nt: Trying to delete \??\C:\mydocs\temp\dac.txt, isdir = 0 >>> 274 34276 [main] rm 7580 unlink_nt: Opening \??\C:\mydocs\temp\dac.txt for removing R/O failed, status = 0xC0190052 > shows that the DOS R/O bit was set. If this attribute really showed up > after you'd called chmod, how did it get there?!? > > > Corinna > -- 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