PHP: Image uploading if fail

I am having an upload image system.

You upload a image, then you crop it and press save.

If you cancel this procedure at after you uploaded the image, the image will remain on the server.

So therefore i tried my idea of making a column in db called "failImage", so when you upload the image, it stores the filename e.g 1111.jpg in the column.

So later if you cancel this procedure either by开发者_StackOverflow社区 shutting down the website or something else, next time you visit, I made a function that checks if failImage is empty.

If it isn't then it deletes (unlink) the value in failImage(which is in this example 1111.jpg) and emptys the failImage column.

This works fine.

But...if you have two windows of my site, and on the 1)st one you upload a image, and then at the 2nd one you refresh the window(f5) the function i made, that unlink the value in failImage runs, and will then occur an error to the previous window you have open, when you try to crop and save it, as it says no such file or directory, as the second window has removed the image you were working with.

I have thought of an solution to this for some time, is there any way I can solve this?

You can make this process much more simple and less error prown, if you split it into two steps.

1. Step: User uploads an image, which is saved in user-account.

2. Step: User can select already uploaded image(s) and crop it/them.

You keep the two steps strictly separated but in order to keep up good usability, you don't show the two steps to the user. If step 1 completes successfully, you automatically invoke step 2.

Advantages:

• If step 2 failes, user can invoke it any time manually.
• No need for complicated and error prown mechanisms as you describe them involving the DB.

I believe dnagirl's solution is the correct one, although I'm not sure how long the file will live in the temporary directory once you upload it. A possible alternative to this is to implement your own temporary directory and have a cron job run to autonomously clean it after, say, a few hours. Basically:

1. User uploads the file
2. Move the file from OS Temp to Custom Temp
3. Prompt them to crop and save
4. On save, move it to the permanent directory
   • When the cronjob runs, it should check the age of the file (see filemtime()); if it's older than the cut-off, delete it.

If you don't feel like doing all that, then I'd say encode a timestamp into the failimage column.

Let me see if I understand you correctly:

1. Upload an image.
2. Edit the image.

Requirements:

• Multiple instances in a browser shouldn't unlink the image.
• The user can come back to the image later if he/she so chooses.

Give the user a Cookie of the file name or id of the image in the database. Place a timestamp (in the database) on the image and every once in a while check your database and delete the expired images. If the user comes back and still has the cookie, let them finish editing the image. Since you can't use cron as you specified, do what another user said. Make a probability of checking the database depending on how much traffic you have and how often you want to verify the "freshness" of the image.

If the user opens a new tab or window within the browser, they will get a replica of the window already open.

Does this sound like something feasible?

Also, you could look at the IP addresses.

As you mentioned ,it fails when user use 2 windows.

Even if user use 2 windows , if they have an id like userid and image have some relation with that id . You can check that user is logged in or not .dont delete the image if user session is there .

check the session end time for the user id and the status of fail image.

Should work ...

just have an 1:M table that allows for a user to have multiple loaded images. Then when you first upload until you save it goes in that directory. Keep track of last logged on time as well, and keep a third field on this 1:M table that tracks the time the file was uploaded (or goto the disk and get the time) and then if last logged on was more than 1 day ago, or something, delete the file... you really need to have a very explicit workflow on what you don't mind your users doing and what is an absolute no-no