"filename.xxx could not be found" for XLS form type select_one_from_file

Description

Description of the :bug: bug or a :rocket: feature; you can also add one of the labels: bug, enhancement, ideas or question

Users have submitted forms and uploaded files for the field select_one_from_file. When I view a submitted form, some files are not available and I get an error.

The one file can be downloaded but the second gives an error. The file that can’t be found in the example above is 170kb.

However, if I export the project’s data, the hyperlink in the spreadsheet works and I can download the file that way.

Steps to Reproduce

I can’t consistently reproduce.

Expected behavior

When I view a submission I expect the file to be available to download.

Actual behavior

Error stating that the file cannot be found.

Additional details

Sometimes a file field on a submission works, sometimes it does not. It doesn’t appear to be based on the individual file size, the filename length, or the file type.

Welcome to the community, @Jean_AFRE! Are you able to see the doc file in your gallery? Are you able to download your file as media zip? BTW, what is the size of the doc media file? Please also let us know the server you are using?

Hi @Kal_Lam

Thanks for responding. I’m using the global server.

We’re uploading different file types (pdf, docx), not only images, so they’re not visible in gallery.

The size of the zipped media file on 45MB and I am able to download and access the files that way.

Looking at your screenshot, it appears that the filename of the second attachment may be causing an issue, specifically having a ‘&’ in the filename. It looks like this char is getting ‘escaped’, to &amp, and this may be causing the lookup to fail.

It would be interesting to see if you can resubmit the same form with the same file a second time, but rename the file to, say, “ToR-ASSL Digitalisation gap analysis and data-led prj scoping-17_9_39.docx”

Confirmed. Having an ‘&’ in the source filename means that the submission may be fine, but if you try to subsequently edit the submission (in Enketo) it will fail to load the file back in. This probably applies to all file types; I tested with an image.

  • Image without & in filename:

  • Same image with & in filename:

I’ll log an issue, but in the mean time perhaps try to avoid any ‘special chars’ in your filenames; the above escaping will probably apply to all HTML reserved chars:

  • < less than
  • > greater than
  • & ampersand
  • double quote
  • single quote