So this is rather - why doesn't Un*x have 'filecopy' syscall? Because it's not that common operation, when you work on something you move it, rename it, modify it AND archive it.

'copy' syscall would be usefull for archiving... or would it?

Besides, unix way is to be ascetic and elegant, avoiding putting messy and slow algorithms under the hood, and filecopy is definitely slow ( you want syscall with fast filecopy - great, here's hardlink for you ).

That is also a reason why rename fails across filesystems, it would be possible to have 'rename' call that works in such conditions ( look at the source of 'mv' command, such non-unix 'complete' design would put all that source into system, this would also add non-determinism to syscalls - normal rename returns very fast, across filesystems rename would take forever )

It seems like you don't appreciate that?

If I'm not mistaken, in the early days mv was _not_ able to move a file across file system boundaries, because it only implemented a rename. In those days you had to copy the file to the target FS and afterwards rm the leftovers on the source FS. Yes, you could call that ascetic. :-)

Actually I got burned few times by this new 'mv' behaviour, you mv something from one dir to another, and suddenly it starts copying without warning.

This is very bad behaviour, this hurts ALOT when you're moving 1G file and there's only 700Megs left free on your partition.

(especially when you're moving between mount -o bind'ed directory on the same filesystem and mv thinks these are two different filesystems)

It seems like you don't appreciate that?

Huh? What makes you draw that conclusion? I don't want a lot of this stuff in the core simply because I'd like the core to be as minimilistic as possible (for one thing, it would encourage new programmers to use modules). It's too late for Perl5, but I can dream, can't I?

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

I don't want a lot of this stuff in the core simply because I'd like the core to be as minimilistic as possible (for one thing, it would encourage new programmers to use modules). It's too late for Perl5, but I can dream, can't I? Well, there's always Python, where you can't do a lot without including at least one module. And then there's C where you can't even do I/O without the help of a library. I love a language where I don't have to remember in which module which function was defined so I can use.

As for your reason, "to encourage new programmers to use modules", most people are interested in getting more people to program Perl by making it easier for new programmers. It seems you have a different view.