Bug #50508

Re-uploading file in backend fails

Added by Oliver Hader about 6 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2013-07-29
Due date:
% Done:

0%

TYPO3 Version:
6.2
PHP Version:
5.3
Tags:
Complexity:
medium
Is Regression:
Yes
Sprint Focus:

Description

Steps to reproduce in TYPO3 backend:
  • upload a file to a folder in the filelist
  • delete that file in the filelist
  • upload the file (same filename) again

Situation:
#1317178604: No file found for given UID

The reason for that is, that deleting the file sets the "deleted" flag for the file object, which does not get purged once the file is physically available again.

50508.html View (11 KB) Oliver Hader, 2013-07-29 09:03


Related issues

Related to TYPO3 Core - Bug #48336: sys_file record doesn't get flagged as delete after deleting a file Rejected 2013-05-17
Related to TYPO3 Core - Bug #50363: Fatal error: Call to undefined method TYPO3\CMS\Core\Resource\ProcessedFile::getUpdatedProperties() Rejected 2013-07-24
Related to TYPO3 Core - Bug #50525: Deleted flag is not updated during file indexing Closed 2013-07-29
Related to TYPO3 Core - Bug #44105: Image size does not get updated Closed 2012-12-19
Related to TYPO3 Core - Bug #51698: Delete sys_file entry when a file is deleted Closed 2013-09-03

History

#1 Updated by Oliver Hader about 6 years ago

See attached stack-trace for details...

#2 Updated by Philipp Gampe about 6 years ago

  • Status changed from New to Accepted
  • Complexity set to medium

@Oli are you working on this?

#3 Updated by Hans-Joachim Reinecke about 6 years ago

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!

#4 Updated by Oliver Hader about 6 years ago

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)

#5 Updated by Oliver Hader about 6 years ago

  • Status changed from Accepted to On Hold

#6 Updated by Ernesto Baschny about 6 years ago

  • Is Regression set to Yes

#7 Updated by Ernesto Baschny about 6 years ago

  • Category changed from 1394 to File Abstraction Layer (FAL)

#8 Updated by Tobias Pierschel about 6 years ago

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.

#9 Updated by Oliver Hader about 6 years ago

  • Status changed from On Hold to Accepted

#10 Updated by Ernesto Baschny about 6 years ago

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?

#11 Updated by Markus Klein over 5 years ago

Is this still an issue on 6.2?

#12 Updated by Sebastian Fischer over 5 years ago

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

#13 Updated by Helmut Hummel over 5 years ago

  • Status changed from Accepted to Resolved

sys_file does not have a deleted field any more

#14 Updated by David Bruchmann about 5 years ago

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.

#15 Updated by Benni Mack about 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF