Migrate filenames to OJS3

Describe the issue or problem
After an upgrade from OJS2 to OJS3, there are no files in files_dir. I suppose that they need to be restored from the backup (also according to https://docs.pkp.sfu.ca/upgrading-ojs-2-to-3/en/upgrade-planning#do-an-inventory-of-your-journal).

The problem with that is that both the directory structure and file names are different between the two versions.
For example, the file that was residing in


should (see additional information) now be named


This is also true about the PDFs displayed on the journal site. They are now located in the directory
submission\proof while previously on public, and the filenames are also changed accordingly.

Files that have been uploaded manually (from the UI) after the upgrade have the proper names and are in the correct directories.

It’s obvious to me that something went wrong during the upgrade, however I did not perform it myself and no upgrade logs have been kept (to the best of my knowledge), in order to see what exactly happened.

I think that the best course of action would be to rename the files from the backup and copy them to the proper directories, however I do not entirely understand the correlation between the new and old filenames/paths in order to create a script.

Could you help with this or offer any other suggestions in case my explanation is wrong?

What application are you using?
OJS (upgrade from

Additional information
The reason I was tipped off about this was an error in php log:

FileApiHandler: File C:/xampp/files/journals/3//articles/477/submission/review/477-1-1512-1-4-20230103.docx does not exist or is not readable!

It seems that the application is trying to reach a filename that it generates (or does it read it from somewhere?), however the file obviously is not there. Some insight (which I don’t have) about how the API works would be helpful.

Unfortunately I haven’t managed to reproduce it, so I don’t know which exact action caused it.

When updating from OJS 2 to OJS 3.2, it is important to ensure that the “files_dir” folder is accessible both before starting the update and during the update process. This is because the files in this folder will also be changed during the update.

If the “files_dir” folder is not accessible during the update, the update process will still complete but there will be errors in the log indicating that the files are not accessible. This can cause problems when attempting to view articles, as the PDF files may not open.

If this problem occurs, it can be very difficult to solve by simply changing the folder names and filenames. In this case, the easiest solution is to update again using the backup.

Thanks for the response.

Could you tell me some cases where files_dir would be “not accessible”? For example permission issues? In order to not repeat any errors if I chose to continue in this way.

I hoped that maybe the part of the upgrade script that performed the migration of files specifically was “easily” accessible, so that I could run only this code to avoid running the entire update… Do you know where I could find this?

Also, do you (or someone else) know how the process of opening the files works? What happens between somebody clicking a “PDF” button on the journal and the file getting downloaded?

Thanks once again.