Re: cvs: php4 /ext/standard basic_functions.c file.c file.h /main SAPI.c

> > Right, what I meant was, shouldn't move_uploaded tell the destructor to go > > away? > > I don't see any good reason for that. Considering you added the automatic > unlink() at a very late stage, I'm sure (hope) most scripts before that > took the responsibility of deleting these uploaded files themselves, which > is essentially the same... True, I was just trying to avoid an extra unlink() that we know will fail. And, could there not be a race condition where a new uploaded file could get the same name as the one you deleted with the move_uploaded_file()? Especially if the receiving script does a lot of stuff between the move and the end of the script. For example. I have written photo album code in the past that received the file upload, copied the picture, ran it through a bunch of conversion routines to produce images of different resolutions along with a thumbnail. For large images this could take 10's of seconds. The way the tempnam() and mkstemp() functions work is that they check to see if the file exists or not to make sure it is a unique filename it is giving you. There is also some entropy involved as well, so your chances are pretty good it will take a while before a filename is reused, but leaving a large window between the move and the bogus unlink isn't the wisest thing in the world as the bogus unlink could come along and unlink an uploaded file belonging to another request entirely. -Rasmus