</OB_Python>

But, as with all things Unix, if you want the hand holding, you can have it. Change 'mv' to 'mv -i' in my example and it won't clobber the file without asking first. Windows and the like assume that you're stupid and that they know better. I don't like that one bit.

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