The unlink command merely deletes a file (or a list of files).

Well, actually, it doesn't delete files. It deletes links to files. In other words, it removes an entry in a directory structure and decrements a file's link count. A file may have more than one link. (See ln(1) for information on hard links.) In fact, even if the link count goes to zero, the file may not be deleted immediately; if there are open file descriptors pointing to it, it'll remain until they are closed.

-sauoq
"My two cents aren't worth a dime.";

Well, actually, it does (or if you wanna be anal, it depends). Please don't spread misinformation

from perldoc -f

unlink LIST
unlink  Deletes a list of files. Returns the number of files
        successfully deleted.

            $cnt = unlink 'a', 'b', 'c';
            unlink @goners;
            unlink <*.bak>;

        Note: "unlink" will not delete directories unless you are
        superuser and the -U flag is supplied to Perl. Even if these
        conditions are met, be warned that unlinking a directory can
        inflict damage on your filesystem. Use "rmdir" instead.

        If LIST is omitted, uses $_.

from perlport

Don't unlink or rename an open file.

Don't assume that a single unlink completely gets rid of the file: some filesystems (most notably the ones in VMS) have versioned filesystems, and unlink() removes only the most recent one (it doesn't remove all the versions because by default the native tools on those platforms remove just the most recent version, too). The portable idiom to remove all the versions of a file is

    1 while unlink "file";

This will terminate if the file is undeleteable for some reason (protected, not there, and so on).

Some operating systems don't have links at all.

Please don't spread misinformation.

I wasn't.

Well, actually, it does (or if you wanna be anal, it depends).

Right. It depends. In other words, unlink() does not delete files; it does something else which might result in files being deleted. I really don't care what perldoc -f unlink says because, in this case the docs are not, as you put it, "anal." Their imprecision is forgivable because it is a messy topic with multiple exceptions depending on operating system and filesystem features.

On Unix, Perl's native platform, unlinking generally removes a directory entry, or "link". Hence the name of the function. Although many files have only a single directory entry, that's not at all guaranteed. In that case, if you call unlink() and pass just one of the file's directory entries, the file itself will not be removed even if unlink() successfully removes the link and returns 1.

Also, on Unix, unlinking an open file works just fine. I've even seen it used on purpose. Nevermind what perlport says; not everyone cares about writing portable Perl.

Versioned filesystems, as you yourself point out, are another example of how unlink() may not delete a file. There is a variable, UNLINK_ALL_VERSIONS, however, which can be defined at compile time to make perl on VMS behave similarly to perl on Unix.

Some operating systems don't have links at all.

And, on those crippled platforms, the overly simplistic explanation given in perldoc -f unlink is sufficient.

-sauoq
"My two cents aren't worth a dime.";

OK - This got voted -- when I answered those complaints in the first place, and got voted even more -- when I tried to delete it. I was right in the first place anyhow.

The questioner asked whether using the unlink command repeadly from a perl script would damage the hard drive on the web server. The answer is "no". There was nothing in the question about arcane technical details of the file system. I left that stuff out on purpose, not by accident. As a matter of fact, my original posting is so far the only one to address the actual question at all. So vote on that.