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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=ijcAjNUbp40H5vy5zapajf8AqIiI62MTbhh7lD71Xgl
	FXKgyAk0/rARe9r0iuc+IBqNXrqzK+nCXdPw5vNDehC01Si+TapYBkWcO72baf2u
	hGb23tQe8IAAFBtn9HH/HG22emJaQnJkTImvBj2aa1w+WSyezL3Eg1MHmK08++fE
	=
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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 s=default; bh=ZOrunvaOYyugk2mZcmHT1h8+m1I=; b=HZA7NQTVxvHHsQ5p8
	+4/YE79MvIeCKT9KFuHMBck56QTSV6joKP1xMvshDfy1eOrDekoIPh0C78XLa4aX
	Q/Furqf4qBvmMSiO5EdV0ro61zO16H9VodfEc7es+vtab//I1qavlTBb55tE1htL
	ywBulqTumBQSKg6Fyvzd+174DY=
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=0.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO: server.obj-sys.com
Message-ID: <535A6FF9.90004@obj-sys.com>
Date: Fri, 25 Apr 2014 10:23:53 -0400
From: Douglas Coup <dcoup AT obj-sys DOT com>
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 AT cygwin DOT com
Subject: Re: rm -f behavior
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>
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 AT obj-sys DOT com
X-IsSubscribed: yes


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