rm -f behavior

[Douglas Coup]

I downloaded the x86/cygwin-inst-20140425.tar.xz file.  I assume all I 
need to do is run tar xvf against this file?  From the output it 
certainly looked like it installed the files.

But I'm not seeing any difference.  I'm still seeing the permission 
denied error on rm -f in the scenarios I've described.

Incidentally, the sequence below should have nothing to do with Perforce.

$ touch dac.txt
$ chmod 444 dac.txt
$ rm -f dac.txt

This is being done completely outside of any Perforce workspaces.

Regards,

Doug Coup

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 10:50 AM, Corinna Vinschen wrote:
> On Apr 25 10:23, Douglas Coup wrote:
>> 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.
> 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
>


--
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