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:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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 <corinna-cygwin AT cygwin DOT com>
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
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--

- Raw text -