X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; q=dns; s= default; b=XqgdPkizkeJ0D0wohHdN2dXcqJBOFJbSx6JXUZi1SUGwLUKXcUjpe j7xYtDVdUKakHu3RzzPd21hZ42ksd5MYzW8t7Sagjyh2V8Sbrs4hshAYEEdOckyR mc1Vd2AQk9iF9FjxEWNZNSD+qMfgRK0PmhFgLTiJJps3y5wKvMCryw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; s=default; bh=pCoz2pUJgoquaw7i8RhGvSr6GA8=; b=UGMlx2NhgrIAqgAS2khH8yjSzTOX ilz1jmrShGhZwoxMUuOaaReOm2coA8Po3S/OG1x9nssum+LbIVls7tjhh+vdM2Ea WmEyM5+i1wX7GFPKR2TTtSRegM3C7nkzqUZeLhTZkFemkbMwDT3T9YmSwpLb+Vdh QNcSr31Pihw2HpY= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: calimero.vinschen.de Date: Fri, 25 Apr 2014 16:50:36 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: rm -f behavior Message-ID: <20140425145036.GE5666@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <5358260B DOT 90807 AT obj-sys DOT com> <20140424142304 DOT GT2339 AT calimero DOT vinschen DOT de> <53592F15 DOT 4040309 AT obj-sys DOT com> <20140424163624 DOT GU2339 AT calimero DOT vinschen DOT de> <20140425121614 DOT GB5666 AT calimero DOT vinschen DOT de> <535A6FF9 DOT 90004 AT obj-sys DOT com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="orO6xySwJI16pVnm" Content-Disposition: inline In-Reply-To: <535A6FF9.90004@obj-sys.com> User-Agent: Mutt/1.5.21 (2010-09-15) --orO6xySwJI16pVnm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Apr 25 10:23, Douglas Coup wrote: >=20 > 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 >=20 > 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. >=20 > 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. Yes, it's all about the DOS R/O bit here. Cygwin doesn't try to start a transaction if the R/O bit is unset. The problem *seems* to be that there's a Perforce transaction manager already enlisted to the files, and that transaction manager is getting in the way. Maybe you just shouldn't try to remove a file from the Perforce-controlled area, unless you removed the file from version control before. Anyway, I applied a patch which covers more transactional error codes, so as to retry the activity without transaction. This should help you along. Please give the today's developer snapshot from http://cygwin.com/snapshots/ a try. Thanks, Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --orO6xySwJI16pVnm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJTWnY8AAoJEPU2Bp2uRE+ggncQAIiHfMUS+NrdavLFiI7ys65Z i6eYRQCgJueWupEJj8V40z5MZvEVmAvGUwDGMPt4pfFnRldUT8GyFFx6UzgZH51e MbmhdwvmUZ/HReT3jQAzSknLfU96Czqlf4QZAkUo5Ndoel370oX9HQBKz749z10T aTo8QnkV0jS9TPAT+ZIKEXO6H4jxE+aqpucVGJHTYkZjJHta3fDZm61Rv6Bq3+yS Pi4cPapXasYmNaMdcXd/uprDWqexQjnrT3xxUjXsU4KWHTPHGoFJonh7F8hxBl3T LH+AlDo9uXNEtihtbkceFj2mfe5HuhSjfGn7nNDjLCmwxZd1Mtb5HOdZtGWgAgyv bfDWl3x6rTefMuXQsFFMZFd40aNtonL44RWmea6zgcvd8d4icBVZnTPTPLpJJfEe lQJ0Y8xUJV9DaNNDqOtFfeFg3PFCtrCePIU2U4mZ0+NBHWqFBw4ryPfB2O5Agbbo eNx3rezvUNuo1Y2mAhbZ7Pnb8El7gJFHfEcjdJnH/Hv8xv1FMODckO4gWxWfuEt9 KemgCcbPA6WIJO3SUm3riEHQbQ3io+tmX0JmJmX2UgHtJe6Wr1RfPb5/eCAlquWx SPtxBDcIXqdPQW509ylrazmSVECIpRZk87kQVPmMKrPIH2+FTJvFjbLamtQzPhV3 vWXMCpdF7D3zDnzGq2bQ =Iq+8 -----END PGP SIGNATURE----- --orO6xySwJI16pVnm--