This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: New rename(2) function
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 1 Aug 2007 18:37:19 +0200
- Subject: Re: New rename(2) function
- References: <20070801163149.GK13674@calimero.vinschen.de>
- Reply-to: cygwin-developers at cygwin dot com
[redirected original mail to cygwin-developers]
On Aug 1 18:31, Eric Blake wrote:
> > Corinna wrote:
> > I don't see anything about rename("a","b") with both hardlinks to the
> > same inode being a no-op. Neither in Linux, nor in SUSv3, nor in IEEE
> > P1003.1 Draft 3. Actually, rename("a","b") will rename a to b, thus
> > decreasing the link count of the file by 1, on Linux as well as on
> > Cygwin.
>
> Huh? SUSv3 states this:
>
> "If the old argument and the new argument resolve to the same existing file,
> rename() shall return successfully and perform no other action."
Yay, I missed that. Lazily I tested on Linux using mv(1). Turned
out to be a mistake...
> It looks like draft 3 of POSIX 200x hasn't touched this area yet, so I'll raise
> the issue again on the austin lists on the mv(1) side of things. But it looks
> like cygwin's rename(2) will need to take this POSIX rule into account, to
> match linux.
*sob*. This requires to open both files and look for the file id.
I'm seriously disappointed about this requirement. You can tell
that your friend Austin or whatever his name is!!!1!
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat