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 $!;
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 $!
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. |