I have been trying to use the multiple selection download and kept having it fail in a certain block of files. I tracked it down to a single entry that when included or done by itself caused the window to "reset" back to the 0th record with 50 spacing and not download. I can probably get the individual to get me the file but that may not always be the case so:

UPDATE: the file for the entry is missing thus the barfing on download. Record show submission as completed with file upload.

1) Any idea what may have corrupted the file upload. Is there a diagnostic to check.

2) Is there a "good" way to directly access the files from the server to recover it. You can find the files in the upload dir under the survey but the file names have no correspondence or association with the records. Any way to decipher the names. (I subsequently realized I could use date but that is cumbersome.) Could the names be placed in the record or just use the index number in someway in the file naming? What advantages is there for names like fu_vcqr27vzfgjqn4n?

3) It was a pain to figure out what was going on with the corrupted entry. I thought it might be file size, browser, star moon alignment, etc. Is there a method to report the failure in the zip file but carry on with the download.

4) It would be nice to dump all the files with one click. It would even be okay if it was done sequentially to their own zip as opposed to a monolithic zip.

I just noticed that the attached file field carries more information when exported to excel or csv. It has the original file name and the name used to store it on the server along with other information in the string. That is very helpful, thank you. I was not expecting it to be different than what is displayed through the limesurvey interface.

Thank you for your entries above, as they pointed me in the right direction.

It happened to be the entry for the largest one of the files I was looking at that was corrupt, and at first I mistakenly assumed that filesize was the culprit.

In this case the database record had the filename recorded as "??tmp_yadayadayada_ext". I was able to deduce from the filesize what the filename in that entry should be, and confirmed through search that it didn't exist in another record. And then after making the manual change in the database to the correct filename, all was then working smoothly. Yes, it was the correct file.

What advantages is there for names like fu_vcqr27vzfgjqn4n?

Add some security ....

1st : is user choose the same file name, we have to rename the file
2nd : If we leave file name clean (and extensions), then all web can access easily to the file ....

It's not perfect, we need a better way (easy way to put this file in a directory not on the web), but take time to fix.

Well thought through and well done on the use of filenames like fu_vcqr27vzfqjqn4n!

The case I ran into above was a database record that contained a different filename from the final name. The filename in the database contained "tmp" and it would seem logical that a temporary name may be utilized during the upload process.

I've run into this a couple of times but haven't replicated it. Perhaps two users were sharing the same persistent token link at the same time and one a second user's entry interrupted the first user's transaction? I know limesurvey isn't designed to accommodate that type of use, though that type of survey respondent behavior might be one plausible explanations.

I'm having the same problem with V.2, any insight on how to fix it?

regards,