This is the mail archive of the cygwin-developers 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: New rename(2) function


On Aug  9 06:27, Eric Blake wrote:
> According to Corinna Vinschen on 8/9/2007 6:02 AM:
> > Even if the ReplaceIfExists member in the FILE_RENAME_INFORMATION
> > structure is set to TRUE, the rename operation fails if 
> > - the target has the R/O DOS attribute set, or
> 
> POSIX doesn't really specify R/O DOS attributes, so we could theoretically
> do whatever we wanted here.  But as the main list had a report about svn
> acting strangely because of its use of R/O attributes, I think we are
> probably better off working around the attribute and doing the rename anyway.

It's not svn's fault, it's Cygwin's fault.  Cygwin's chmod always sets
the R/O attribute on a file if none of the write permission bits is
given in mode.  It makes sense to do this when ntsec is off, or on FAT.

Maybe we should not do it for the (in my eyes) standard case NTFS with
ntsec.  The DOS R/O attribute more closely resembles the ext2 'i' file
attribute (see `man chattr'), rather than any access permission bits.

OTOH, we have to live with the R/O attribute anyway...

> > - the target is an existing directory, or
> 
> Sheer bug on Microsoft's part - I guess we have to work around it.

Indeed.

> > - the target is a currently executing file.
> 
> POSIX describes this - you are allowed (although not required) to fail
> with ETXTBSY.  In fact, I would recommend failing with ETXTBSY, even
> though Linux does not do this, since otherwise it would be possible to
> overwrite in-use .dlls, which is a no-no in the cygwin /bin directory.

Fortunately the above claim on the MSDN man page for
FILE_RENAME_INFORMATION is not correct.  You *can* rename an executable
which is currently executed.  It's not the only wrong information on
that MSDN page.  It also incorrectly claims that it's impossible to
rename a file which has open handles (which is probably just a
generalization of the "executing an executable" case).

What *is* correct, unfortunately, are the R/O and directory restrictions.

Really strange is the fact that it's impossible to rename a directory
which contains files with open handles:

  $ mkdir a
  $ touch a/file
  $ cat >> a/file &
  $ mv a b
  [...]: Permission denied.

That's incredible, because the below steps work fine:

  $ mkdir a
  $ touch a/file
  $ cat >> a/file &
  $ mkdir b
  $ mv a/file b
  $ rmdir a

So what's the gain of not allowing the same in one rename operation?

I'm also wondering if there's any sense in implementing the above
workaround in Cygwin, just to be able to rename directories with open
files in it.  It would have to work recursively (shudder)...

> > which is impossible to implement with the given NT behaviour.  Grr.
> 
> Well, we already know of other operations that POSIX requires to be
> atomic, but which Windows makes it impossible to implement atomically.  No
> skin off my back; you are doing the best possible in spite of the lousy
> semantics of the underlying OS.

Thanks :)


Corinna

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


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