It's called 'unlink' because it removes the directory entry (file name), which can be considered a 'link' to the actual file (the data).

Note that (on Unix) multiple file names (hard or symbolic links) can point to the same file.  The unlink system call (or the user command of the same name) deletes the name, the file itself is only deleted if that name was the last (hard) link/reference to the file.

"what actually does unlink do?"

unlink explains what it does and how to check for failures.

"what actually does unlink do?"

The post by Eliya is very close to the mark. Since we are talking about "unlink", another point is of interest especially if you are ever writing a program that updates software.

This discussion applies to Windows also! A "file" is a collection of data bits on the disk. The directory has a "human readable name" that "points" to those bits. The "open" translates the "human readable name" into a data structure that the file system uses to access the data bits, this is the "filehandle". Once a file is "open", the "name" doesn't matter <- this is important. If the file is open, you can change the name or even delete the name without affecting the data bits!

Its been a while since I wrote a software updater for a continuously running system, but basically the idea is to copy all the important stuff onto the target. Say x.dll would get a temporary name of x_temp.dll. Then, x.dll gets "unlinked". Everyone who has this file "open" and is using it, continues to use it even though it has no "name". Then, x_temp.dll is renamed to x.dll and new requests for "x.dll" will get the updated file. The actual "old x.dll" file bits will get "deleted" when then are no longer in use (everyone using it does a close). "Delete" in this case means to mark that area of the disk as available for other use.

From say the Windows command line, you might see something like >del X, unable to delete file X, file is in use. However the Perl unlink 'X' command will succeed.

the above was just to round out discussion of "what does unlink" do - and it is a bit different than command line "delete". Sounds to me like the most likely thing in OP's scenario is wrong permissions on the directory. Unlink of a read only file is completely ok. Anyway, Perl "unlink" does what a UNIX person would expect, even on Windows.

del X, unable to delete file X, file is in use. However the Perl unlink 'X' command will succeed.

Its been a while since I played with FAT/FAT32, but NTFS won't let you unlink a dll

This was on W2K Server which is NTFS. I don't know about FAT32 and how that might or might not work. That's a "dead" file system anyway. Yes, there are some implementation details about this and my memory is a bit foggy. I think that I might have had to rename the .dll and then unlink it. But I was able to get an "in use" .dll name removed from the directory and replaced with a new file without affect upon currently running processes.

Didn't mean to write a tutorial on software update - the main point is that "unlink" does something different than "delete". And that it is definitely possible to "unlink" a file that is currently in use because the "human text name" is not how the file system deals with the file, if the file is "open" and being accessed via the file handle. The actual "deletion" occurs when the file is no longer in use.

Of course in the scheme that I described, there are significant complications in the implementation of how a potentially very long lived process gets notified of this update and how it should go about dealing with it. This whole "update" scenario can become very complicated. However, I am confident that Perl unlink can make things happen that the Windows command line would not allow.