PDFs lost because of issue 10758

Software Support
1

The release notes for 3.4.0-9 has this annoying but innocuous bug fix.
#10758: Deleting a galley does not delete associated submission files

I’ve not seen anything here, but that bug fix was changed in Github on March 20, 2026 to:
#10758: Deleting a galley does not delete the right files (and potentially deletes an unrelated one)

We only just found we had been suffering data loss because of issue #10758 and have now been on a process of trying to identify the impacted galleys and restore the missing files.

Of course we didn’t know that’s what had happened we got the report of the missing PDFs because the release notes for 3.4.0 haven’t been updated. Only the Github issue was updated.

I would like to see some comms from PKP on this to raise awareness. And some guidance on how we might identify the damage.

3

Hello and thank you for the post @Jim_Nicholls ,

I can see this would be frustrating. I’m not sure of a simple way to repair the damage. It’s going to take a bit of manual work. I tried a few things and one way was to go to the DB and check the files table and then compare it with the files path. Depending on how many files and directories there are that can be tricky.

A potential way to identify the damage would be to do a count of the files table in the DB and compare them.

For mysql, here is a query I ran that will count the files in a particular folder

SELECT 
    SUBSTRING_INDEX(path, '/', (LENGTH(path) - LENGTH(REPLACE(path, '/', ''))) ) AS folder_path,
    COUNT(*) AS db_file_count
FROM files
GROUP BY folder_path;

image
image469×259 3.13 KB

You can either compare the file counts of each directory to this list manually or I found with a bit of google searching you can save this list as a text file (db_counts.txt) in the files directory (right before /journals) and run this script below with git bash to at least find which of these do not match.

Note: the format of the file must be path then count value on each line.

while read -r folder expected_count; do
    # Count actual files in the folder (ignoring directories)
    actual_count=$(find "$folder" -maxdepth 1 -type f | wc -l)
    
    if [ "$actual_count" -eq "$expected_count" ]; then
        echo "(Good) Match: $folder ($actual_count files)"
    else
        echo "(Bad) Mismatch: $folder (DB: $expected_count, Disk: $actual_count)"
    fi
done < db_counts.txt

image
image624×342 5.05 KB

This should narrow down the search to check those folders that are (bad). Check against the files expected for the DB vs physical files in the directory to make sure they actually exist. I think this will highlight that there might be a problem when the DB count is less than the Disk count ( everything in the database should be in the folder).

4

Hi @Jim_Nicholls,

The first phrasing (“delete associated submission files”) reflects how the issue was reported to us (originally in a forum post). As noted in the issue, in March this year, the title and severity were updated to reflect the possible deletion of the wrong files.

The issue was fixed in OJS/OMP/OPS 3.4.0-9, which was released about a year ago.

There’s a more specific way to check for missing files described in the issue here:

Regards,
Alec Smecher
Public Knowledge Project Team