Broken links to Publisher library files after upgrade to 3.2.1.1

Weird thing after upgrade to 3.2.1.1 from 3.1.4.

Upgrade script showed no errors in library files schema.

Every file existing in DB registered under library_files now produces a blank page after click from both front and back.

.

Trigger url seem ok : https://domain.com/$$$call$$$/api/file/file-api/download-library-file?libraryFileId=187

File is present in the catalogue context and has suitable permissions.

DB debug presents right syntax =

file_id, context_id, file_name, original_file_name, file_type, file_size, type, date_uploaded, submission_id, public_access FROM library_files WHERE file_id = 93 AND context_id = 32 \x$
PKP-Database-Logger 1601033791.1887: \n(mysqli): SELECT * FROM library_file_settings WHERE file_id = ‘93’ \xc2\xa0 \n\n,

Queried record is actually present in DB

Zrzut ekranu z 2020-09-25 13-42-20

Ojs debug shows nothing but blank page

Zrzut ekranu z 2020-09-25 14-00-46

Browser debug shows code 200 but bad file size.
Initiator - /lib/pkp/js/classes/linkAction/PostAndRedirectRequest.js?v=3.2.1.1

Newly added files does not show any above symptoms.

We had that too. The temporary solution was to rename the files in the {files_directory}/contexts/{journalid}/library/filexy.pdf to filexy-OTH.pdf if it was uploaded to the “Other” section of the publisher library.

However, we already have a complaint by a publisher that the filenames should remain untouched.

@asmecher : Don’t know, why this change had been introduced - we and the publishers are unhappy with that.

Hi all,

This is likely related to Submitting file to Submission Library overwrites Publisher Library files · Issue #5471 · pkp/pkp-lib · GitHub – see the description there for more information. It should copy files to the new expected location (doing automatically what you describe doing manually, @mpbraendle), but if the upgrade script is not permitted due to file permissions, you should have seen warnings during upgrade. Did you see anything like that?

Regards,
Alec Smecher
Public Knowledge Project Team

Yes @asmecher - this was exactly the case. I fixed the permissions and ran the upgrade script a seccond time, but then it did not copy the files. That’s why I did then manually.

Hi @mpbraendle,

Ah, that explains it. Running the upgrade script a second time won’t re-run the same tasks that had run earlier – after a successful upgrade (warnings aside) the version number in the database will be updated, and after that OJS won’t run upgrade stages from previous versions.

Regards,
Alec Smecher
Public Knowledge Project Team

Fortunately, I kept the log of the first run.

1 Like