I ask a different question: why aren't "rename" and "unlink" in a seperate module like "copy" is? (I know, the reason is historical.)

Oh, and it's called "unlink" because that's what it's called in the underlieing POSIX lib. Perl is full of Unix-isms like this.

Perl IS portable Unix, that is it's strength and personality. (btw this recent flurry of windows programmers without unixy background using perl seems to confirm how strong and usefull this design philosophy is).

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. :-)

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 tried to answer this earlier, but I got nowhere. There's really no good answer to 'Why isn't there a "copy" function?'. I could say it has to do with there not being an equivalent OS call and C function (like "rename" and "unlink"), but like you said, manupilating files is very a common activity in perl.

Keep in mind that "copy" can be created from other system calls (open + sysread + syswrite + close), while "rename" and "unlink" cannot.

Then again, if we started including everything common into core... I guess the answer is bloat protection. That begs the question "Should many core functions be moved into modules?" Well, not in perl5, that would break too much, but that's something we could do in perl6.

Ah well, just felt like writting a mini-essay.

A better question is why Unix does not have a copy function to copy files. The operating system can do a better job copying files than user code. It can be much more efficient with network file systems, knows more about file attributes, better optimize IO, and could implement copy-on-write behavior. A copy() that only worked within a filesystem would be similar to rename().

Consideration is currently going into Linux to add sendfile file-to-file semantics, which would be basically equivalent to a copyfile system call. The major problem is that, if you were to copy a 2GiB file, for example, it would freeze the system as the kernel took up all available processing time doing the copy. So, copyfile system calls would tend to expose a local DoS attack, because they happen in a place where execution can't normally be interrupted to allow for multitasking.

Good point,
On unix, File::Copy needs to be called when moving a file, but on Windows Win32::FileCopy is more reliable.
copy-ing a file works best when the direct OS API's are called. (has to do with file permissions etc... ).

---------------------------
Dr. Mark Ceulemans
Senior Consultant
BMC, Belgium

On unix, File::Copy needs to be called when moving a file,

If you like to be surprised or use non-flexible API, you'd use File::Copy. If you're smart, you'd use system cp. Things that are easy with system cp and awkward with File::Copy include:

    cp file1 file2 dir
    cp -r dir1 dir2
    cp -p file1 file2
    cp exe1 exe2

Not to mention that I can stick an 'r' or an 's' in front of it, and copy from one machine to another.

Because unlink (and rm) does precisely that, unlink a file. It doesn't remove a file, although the effect of unlinking may cause a file to be removed.

To understand that, one first needs to know how a (Unix) filesystem works. This is a sketch of a file:

 
     +----------+
     | #i-node  |        +--------------+
     |          |------->|   Content    |
     +----------+        |              |
                         |              |
                         |              |
                         |              |
                         |              |
                         |              |
                         +--------------+

Then were is the name of the file stored? For that, we need to know how directories look like. Directories look like files, they have i-nodes as well, but what is interesting for us the content part. It looks like this:

    +-------------------+
    | name1 | #i-node-a |
    | name2 | #i-node-b |
    | name3 | #i-node-c |
    | name4 | #i-node-b |
    +-------------------+

What unlink is doing is that it removes one entry from the directory. A link disappears, hence the name unlink. Now, if after performing an unlink, the number of links to an i-node is 0, and the file hasn't been opened, the file will be removed by the kernel.

Hence, the question shouldn't be "why isn't unlink named rm?", but, "why isn't rm named unlink?".

Because then you would have to include all of these other "must have" functions and Perl would no longer be Perl. It would be PHP.

Yes, it is common, that's why it is a Core Module.

(The real answer has already been provided -- Unix heritage.)