500 error when downloading query attached file

Software Support
1

Hi,

One of our journals has encountered an interesting problem. When the author uploads a file to a discussion message / query, the editor can not download it. The editor gets a 500 error.

The original file is docx. The label visible in the discussion message shows the expected author, role, original file name label. The file exists on the server and it is fine.

When I check the detals for the 500 error, I see this:
/files/journals/25//articles/69145/submission/query/69145-85-89972-1-18-20180411.txt does not exist or is not readable!

So, for some reason OJS has decided that the file is a txt file? What could cause this? Is txt a fallback and why is it used here? The saved file type for the file is application/vnd.openxmlformats-officedocument.wordprocessingml.document.

Is it possible, that a long filename causes this problem?

2

hmm, could this cause it: https://github.com/pkp/pkp-lib/blob/master/classes/file/FileManager.inc.php#L529

in submission_files table the original_file_name does not have the .docx part for some reason. So could that fill the !isset($fileExtension) rule there?

But why would the original file name be saved without the file extension there?

3

@bozana or @asmecher, do you have an idea what might be going on here?

OJS 3.1.0.1 and this is happening only in one journal and one submission that I know of.

4

Hi @ajnyga

What is the original_file_name i.e. is it longer than 127 characters?

Hmmmm…
Bozana

5

Hmmm… This function does consider the file extension: https://github.com/pkp/pkp-lib/blob/master/classes/file/FileManager.inc.php#L484. What do you get there as result?

6

Hi @bozana, I can not test this right now, but I already tried uploading a file with the exact same file name and had no problems. I mean OJS cuts too long file names, right?

Our production server has latin1 encoded tables, so when you save data you can “see” the utf8 bytes in the database table. It works fine and we will fix the issue next summer, but I was thinkin: is it possible that the cutting of the file name is not working properly there because instead of real uft8 chars you have for example “ü” in the database table???

7

Hmmm… It truncates the name only if the name length is > 127, but the function utf8_strlen is used to determine the file name length. Then later the function utf8_substr is used to truncate the name. Maybe this is leading to some problems… Hmmm… It seems like the problems lies somewhere there… :slight_smile:

8

yes thanks, I have to make a test installation with similar settings as our production. As I said we will probably fix the encoding issue next summer and this is the first issue like this, so I think we will be ok even if this is not getting solved. It seems to be unlikely that the needed conditions are met because we got a lot of submissions and uploaded files all the time…