--- Wade Smart <[EMAIL PROTECTED]> wrote: > Yesterday many teachers uploaded new pictures. Right now all the original > picts > are 600 and all the thumbs are 644. I know for sure one teacher deleted a > file > and it did not remove the original files. > > As a note - I did find this yesterday. One of the teachers only uploaded one > picture. That one picture was permission 664. Im not sure why though. > > Their original server was windows but have since moved to some version of red > > hat. I think (if I push hard enough) they will be moving to a ubuntu server > soon. I dont think RH has any extra feature like you were saying. > > Wade
Are the images being uploaded via PHP and an HTML form or via FTP? As you probably know, the basic operation of uploading a file via PHP is to have a web form with a <form enctype='multipart/form-data' ...> and an <input type='file' ...>. When the user selects a local file and submits the form, the file is uploaded to a temporary location (often /tmp on Linux) with a random temporary filename. Your PHP script (named in the action property of the form tag) uses is_uploaded_file() to check to see if the file has really been uploaded and not a POST spoof and that it is of the correct type and size which is allowed to be uploaded to your application. Then you use move_uploaded_file() to copy the temporary file to a directory which the PHP (ie Apache) user may write to. It is often a good idea to have this directory be outside the web space and create a special handler script to get the data when requested by the browser. Under these conditions, unlink() should work. However, if users are uploading files via FTP or SCP/SFTP with their own user names, PHP won't be able to touch them without some additional considerations. I don't know why you would be seeing different perms for the uploaded files. PHP scripts can do this to files uploaded via form but it is more likely a problem with FTP-style uploads. James
