Think of an autoincrement field in a database (why not use that? ...), or a setup with a little file holding the number, pretty much like the "web access counters" of a decade ago.

To augment revdiablo's reply, if someone is already using a database for things related to the task at hand, then for sure, it makes better sense to use a database to create this sort of "guaranteed unique" identifier. But if there is no database facility on hand -- and it's just a matter of using the file system -- then installing a database just for this purpose is more trouble than it's worth.

On the other hand, using a "little file" somewhere doesn't help much either, really -- it just adds another few ways that the "guaranteed unique" naming could fail (I've seen it happen).

For instance, if there is any sort of error when writing the lastest (or next) increment to that little file, it might end up unchanged, or worse yet, empty -- and unless you're really careful about that, you could start you're sequence over at 0 -- perhaps multiple times -- without noticing until it's too late.

When you are careful about it, you'll find yourself looking at the directory contents anyway, to determine the latest-used file name (as in the OP) or at least to confirm that a file name you make up on the fly does not already exist (as in the solution proposed by tachyon), so you might as well just stick with that -- it's both necessary and sufficient.

If I were looking for sequential file names, as suggested by the OP, I would start with

 $last = (sort { $b cmp $a } readdir( DIR ))[0];
[download]

so that I easily get the latest item in the directory and increment from there.

But in any case, if there were a chance that the script would be run in concurrent processes on the same directory, I'd add a semaphore file, so that the steps of checking directory contents and creating the new file would be an atomic unit, doable by only one process at a time.