Unix has been around for longer than Windows has with fewer changes to basic things such as this. While this is a poor measure of correctness, I think it says something.

It says something. Quite what it says is open to question.

Of course the behaviour makes sense to Unix heads familiar with how the C rename() operates. Which is a plus. Less to learn.

Apart from this, and being simple to implement, is it a good decision?

demerphq says that it's "much more common to want to rename things and overwrite what was there before". This is reasonable, but (after a quick grep of the Perl I have laying around) it doesn't match my experience.

The current behaviour certainly makes coding some operations harder. If rename failed if the new filename existed we could do:

rename( $old, $new ) || die $!;
[download]

and be certain that $new won't be damaged if it already exists. However, with the current behaviour we either have to abandon rename completely and spend a lot of time and effort doing sneaky stuff, or do something like :

! -e $new && rename( $old, $new) || die $!
[download]

which is both longer to type, and has a race condition ($new could be created between the die and the rename).

Personally I would prefer rename to fail by default with an option to overwrite. It would make my code more robust.

Personally I would prefer rename to fail by default with an option to overwrite. It would make my code more robust.

You'd still get the race condition, unless the underlying C API call was atomic - and we've seen that in a lot of cases this isn't the case (i.e. you'd first have to check for the file's existence, hence the race condition.)

Michael

You'd still get the race condition, unless the underlying C API call was atomic

I'd hoped that it would have been obvious that this would need to be implemented without using rename(2) :-)