If you unlink a directory (as root and flying the -U flag), you will indeed damage things. Use rmdir instead. Advice straight from perldoc -f unlink.

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.

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.

Let me expand on my original question with an example...

Lets say that the 'unlink' command is used when the directory, or files, that 'unlink' will remove are not present on the drive due to being manually removed. So, basically, unlink isn't finding the files to remove. Can this damage the drive?

The reason for my original question was that I am trying to figure out if the use of the 'unlink' command caused the file structure on one of our servers to be completely wiped out causing the loss of all data on that drive.

thank you...lis

... Can this damage the drive?

No, not really. unlink isn't some unpredictable magical fairy {grin}, however, user beware

#!/usr/bin/perl -T
unlink $ENV{HOME}
__END__
Insecure dependency in unlink while running with -T switch at - line 2
+.
[download]

It is possible that you're getting tainted data, and that combined with the forementioned documented behaviour ... i hightly doubt perl's unlink is the culprit.

Be sure to read perlsec (and turn taint on), and rule perl out as a culprit.

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

1. If the agruemnts passed to the unlink call are generated from user input, check that input very closely. to amke sure no one can pass in some data to destory files you dont want to destroy.
2. Run the webserver software as a low privilage user, and only grant that user access to files it needs