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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat