-
Notifications
You must be signed in to change notification settings - Fork 4
Description
After running unduplicator, in some cases subsequent actions resulted in exceptions because the processed file for a delete sys_file entry still existed. (I noticed this becase I ran a sanitize filenames command afterwards and apparently some filenames were not yet sanitized).
(Apart from that, I finished my migrations with changes in PR #3 and this can be fixed manually.)
Important! It is important to always remove the processed file itself and the entry in the database table sys_file_processedfile (not just one or the other).
Reproduce
- A duplicate entry exists, e.g. with uid 1 and uid 2 in sys_file
- For both, a processed file entry exists
- Unduplicate the entries (sys_file entry with uid 1 will be removed)
- Do some additional action, for example rename the file (I did this via the CLI with a script which should sanitize filenames like this):
$sanitizedTargetFileName = $sourceStorage->sanitizeFileName($currentFileObject->getName());
if ($sanitizedTargetFileName !== $currentFileObject->getName()) {
$currentFileObject->rename($sanitizedTargetFileName);
}
Now the exception is thrown in ResourceFactory and shows the uid (e.g. uid=1)
In ResourceFactory.php line 223:
No file found for given UID: 1
The processed file can be removed:
mysql> select uid,original,storage,identifier from sys_file_processedfile where original=1;
Result, for example:
+---------+----------+---------+------------------------------------------------+
| uid | original | storage | identifier |
+---------+----------+---------+------------------------------------------------+
| 1085273 | 1 | 1 | /_processed_/3/c/csm_myfile_975bcb8fba.jpg |
Remove processed entry (manually):
!!! It is important to always remove the processed file and the entry in sys_file_processedfile.
-
mysql> delete from sys_file where original=<uid of sys_file which was removed> -
rm -f fileadmin/_processed_/3/c/csm_myfile_975bcb8fba.jpg