This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rm -f behavior

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.

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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpADgFm5nRFs.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]