TYPO3 Core

Can't reproduce this issue on v13. I created very deep structure, but renaming is working without any problems. Maybe this related to your environment setup?

Could you provide more details? How to reproduce this issue? Directory overview or environment setup?

The directory structure is at least 7 levels deep.
It is
TYPO3 10.4.37
PHP 7.3.33
Unix
MySQL 10.4.31-MariaDB

It's possible the server had a timeout, but isn't it strange, that the identifier_hash and folder_hash are different for the duplcate entries?

@Anke Altintop did you check if those files with incorrect hashes in the DB exist on the server? At the moment, I see that if I remove a file manually and change the folder name where this file was stored, the file record in the DB stays untouched (no hashes recalculated, etc.). Can you verify if the problematic entries in the DB are not marked as missing=1?

The whole process looks like this (TYPO3 13-dev):

- You rename a folder in the TYPO3 panel.
- TYPO3 fetches all files from the DB in the changed folder (ResourceStorage::renameFolder() => $fileObjects = $this->getAllFileObjectsInFolder($folderObject)).
- TYPO3 changes the folder name on the server and returns an array with mapping (old identifier => new identifier for files, etc.).
- TYPO3 updates data for each file in the DB based on the mapping configuration.

This data update is done by executing separate DB queries for each file. If something goes wrong during this process, you can end up with database rows where not all identifiers were updated to the new one. Then, if you run the indexer task from the Scheduler, it will create new records in the DB for files in the renamed folder and its subfolders. At the same time, it will mark files with old identifiers as missing=1 (those that were not processed when something went wrong as mentioned before).

Can you verify if that might be your case?

At this point it is a bit difficult to recap everything because we cleaned up the system after we found the mistake. But I am pretty sure, that the files existed and the editor only renamed the folder on lets say first or second level. So somewhere on a deeper level of the folder structure the errors popped up.

I will try to reproduce the behavior on a staging system as soon as possible.

I can't reproduce the behavior anymore. Maybe it is fixed anyway at v13.
We can also close the ticket at this point. If it pops up again, I will create a new ticket with detailed information.

Thanks for your tests so far.