Store the files where the webserver won't serve them, no matter how hard users try to guess their names.

Generate a new unique key for each user who needs to access a file. Store this in a database of some sort that associates that particular key with the name of the file to serve. This can be a flat file (but watch out for locking!), a tied hash (fast and reasonably easy to set up), or a relational database (probably overkill unless you're already using one).

Instead of redirecting the user to a temporary file with a randomly-generated name, redirect the user to another CGI program that takes in the unique key, looks up the appropriate file in the database, then serves the file to the user.

Bonus tip: look into the Content-Disposition header to set the filename appropriately.

Thanks for your information. I've Google'd "Content-Disposition" for about an hour now trying to get as much information on it as I could.

From what I could tell, its primary use is to set attachments through the headers of the page (or in some cases tell the download box to stop being a file hog and send it through the browser instead.

I've done something in the past where I read the file into memory, tossed it in a whatever-named zip file and I pushed it to the user. I COULD do that again if necissary but this brings on another question.. Is it possible to rename a file and push it through a web page somehow without ever having a second copy of the file?