TYPO3 Core

You can´t open the fileadmin folder containing the once again uploaded file even.
Same error message.
Provisional solution: Deleting the sys_file entry of that file via phpMyadmin. This is forcing Typo3 fileadmin to create a new sys_file entry with a different uid. Now the folder and it´s content are available again.
This bug is very bad on production systems. Imagine authors having uploaded hundreds of files and then all of the sudden these are no longer available for content editing.
I´m just short before rolling out a new site and the editors have to upload and integrate a lot of files.
Really can´t understand status "Should have". This is an urgent "Must Have"! I´ve been spending several hours on testing this happens only in case of same filename.
Thanks for everyone working on a solution!

Hans-Joachim Reinecke wrote:

You can´t open the fileadmin folder containing the once again uploaded file even.
Same error message.
Provisional solution: Deleting the sys_file entry of that file via phpMyadmin. This is forcing Typo3 fileadmin to create a new sys_file entry with a different uid. Now the folder and it´s content are available again.
This bug is very bad on production systems. Imagine authors having uploaded hundreds of files and then all of the sudden these are no longer available for content editing.
I´m just short before rolling out a new site and the editors have to upload and integrate a lot of files.
Really can´t understand status "Should have". This is an urgent "Must Have"! I´ve been spending several hours on testing this happens only in case of same filename.
Thanks for everyone working on a solution!

Don't delete the sys_file record, but rather remove the deleted flag, since this is the origin of the problem.
The regression, that caused this problem has been reverted in all branches in between and will be released.
An accordant change in the indexer task now explicitly removes the deleted flag on existing files - see the File Abstraction Layer Indexing task in the scheduler and run it (Git versions currently only)

We ran today exactly in the same issue. I totaly agree with Hans-Joachim " This bug is very bad on production systems." it would be very great if there would be a qick solution for this problem.

Olly: This will be solved as soon as we have #51698 in, right?

Maybe there will be need for some "cleanup" task to get rid of sys_file's that were not deleted before? Or would the reindexing scheduler task already do that?

Is this still an issue on 6.2?

Tested it in trunk and its working. After upload the filelist is usable and the file gets shown in the filelist.

Hi,

I discovered an issue where the problem is not really solved yet:

Uploading a *.t3d-file in the database is written /user_upload/... but the file is not found there but in /fileadmin/upload/...

I changed than the path in the database-table sys-files and can proceed with import.
After the import calling the extension-manager produces an error again as the file is moved then to another location in fileadmin.

The extension I tried it with is t3onepage.