From: Andreas Schwab <schwab@suse.de>
To: Ketil Froyn <ketil@froyn.name>
Cc: =?iso-8859-1?Q?J=2EA=2E_Magall=F3n?= <jamagallon@ono.com>,
       linux-kernel@vger.kernel.org
Subject: Re: unexpected rename() behaviour
References: <47ED8858.9000401@froyn.name> <20080329011656.7c38265a@werewolf>
	<47EE2072.7000504@froyn.name>
Date: Sat, 29 Mar 2008 13:36:38 +0100
In-Reply-To: <47EE2072.7000504@froyn.name> (Ketil Froyn's message of "Sat\, 29
	Mar 2008 11\:56\:50 +0100")
Message-ID: <jesky9g10p.fsf@sykes.suse.de>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1190
Lines: 29

Ketil Froyn <ketil@froyn.name> writes:

> Is this a corner case undefined by POSIX, for instance, or does POSIX
> explicitly say that this is the correct behaviour?

POSIX explicitly requires that behavior.

> So given the case that it is a requirement that oldpath should be removed
> after the rename(), does all software need to check whether oldpath and
> newpath are existing hard links referring to the same file, and if so,
> call unlink(oldpath) instead? I would guess that lots of existing software
> doesn't.

I don't think there are many programs that encounter that situation.
Probably in most cases the new file was created by the program and
guaranteed to be different from the old file.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/