Do you often upload files using upload components? Is your space large enough to allow for the processing of redundant files? The redundant files mentioned here refer to the files that are no longer associated with the information after the user modifies the information or misoperation, and these files occupy considerable space over time.
The following conditions may result in redundant files:
1. The user modified the original information.
The user may change the information while changing the upload file, and the changed file left on the server;
2. Users in the release of information in the process of operation errors, System prompts error, the user returned, uploaded with the original file different files, the original file left on the server;
3. Deleting information does not delete the uploaded file associated with it.
In order to appear in the above several situations, will be redundant files disposed of, I have taken some may be some cumbersome approach, but for the poor space, cumbersome on the point bar. The following methods are limited to the use of file upload components of the operation, if the file exists in the library, the hope can also be a reference.
Let's start with the upload.
Uploading files can take two different ways:
1. Information warehousing and file upload at the same time operation;
2. First let the user upload files, and then information warehousing;
I've used the first method before, and then I give up when I do this kind of function. Although it can upload files related information, such as the number of files, file names, etc. and information at the same time to write in storage, but the shortcomings are also obvious, such as the possibility of processing errors greatly increased; Allow users to upload multiple files need to add multiple <input type=file> loop processing, a mistake, All over again; If the user has a request for the location of different files, it is difficult to handle and so on.
Using the second method, each upload can be individually controlled, but need to upload the information such as [Upload=***]******.***[/upload] in JavaScript to write back to <textarea>, when displayed with UBB processing. I am not sure about the reliability of JS, but the fish and bear cake can not be both, give the fish and take the bear's paw.
Here to insert the number of files uploaded control, some students to upload the number of write into the table, or with the session, I feel is not flexible, such as user changes, how to make the number of uploaded files corresponding changes? It's going to take some effort. My method is to Judge <textarea> [upload] ... [/upload] The number of users, if you want to modify, from <textarea> Delete to modify the [upload] ... [/upload] can be uploaded up to the allowable number.
Upload, the file name generally with the upload time plus random number of replacement, so do have two purposes, one is to ensure that the file is not the same name, the second is to avoid illegal characters in the filename caused the uploaded files can not be displayed correctly.
But the files that I upload in every article, in a separate folder, the name of the folder is also used to generate a random number of times, this is to delete files to facilitate the operation----as long as the deletion of a folder on the OK, imagine from a relatively small folder to delete the folder, It's still a little bit more effort than finding the files you want to delete from a lot of files.
Here's how I do this for operations that might produce redundant files:
1. When deleting files.
As mentioned above, just delete the folder associated with the information.
But this folder is written to the library table, and I do this: set up a <input Type=hidden Name=filepath> in the information release form, and when uploading the first file, generate the folder name, [upload] write back < Textarea>, the folder name is written back to filepath, before each upload to determine whether there is a value in the control, if there is no longer generate folder name. When you modify the information, you can also ensure that the file is uploaded to the original folder.
2. When modifying information.
When the user changes the information, said previously, as long as delete <textarea> [upload], can upload other files, but originally uploaded (that is, the user deleted [upload] identified) that file left on the server. At this point, I traverse all the files under FilePath (this is one of the purposes of the folder) to determine whether each file is in <textarea>, if not, delete it. The simple way is to find out whether the <textarea> string contains the file name obtained from the folder, if it is not insured, you can also use regular expressions to obtain the file name in the middle of <textarea> [Upload][/upload]. Compares the file names that are physically present in the folder.
3. When information is released.
Users in the release of information, may be previewed after the uploaded file is not satisfied with the return to modify, this time the operation is the same as above, that is, in the release also than the filepath in the filename and the file name in the <textarea>. This will certainly affect the speed of the release, in order to save space, had to change space for time.
There is also a situation: after the user uploaded the file, did not have time to release, turn off the browser, go to other pages, or other surprises, this time will cause a site space with any information is not associated with a folder. To handle this situation, I added a table that, while generating the name of the folder, was saved to the table, the information was released, and it was deleted from the table. In this way, those "orphaned" folders are left in the new table, and administrators can delete the folders in the table every once in a while, cleaning up these "orphaned" folders.
Using the above method, you only need to record the folder name in the table without having to record the uploaded file name (the filename exists in the body of the message).
Of course, there are other situations, such as when the user uploads a new file, and then closes the browser, and there are redundant files in the upload folder. However, the above processing, has made the possibility of redundant files greatly reduced, if you feel it is necessary, can be more detailed, but also more cumbersome processing:
