Project

General

Profile

Actions

Bug #50508

closed

Re-uploading file in backend fails

Added by Oliver Hader over 10 years ago. Updated over 5 years ago.

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

0%

Estimated time:
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.


Files

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

Related issues 5 (0 open5 closed)

Related to TYPO3 Core - Bug #48336: sys_file record doesn't get flagged as delete after deleting a file Rejected2013-05-17

Actions
Related to TYPO3 Core - Bug #50363: Fatal error: Call to undefined method TYPO3\CMS\Core\Resource\ProcessedFile::getUpdatedProperties()Rejected2013-07-24

Actions
Related to TYPO3 Core - Bug #50525: Deleted flag is not updated during file indexingClosedOliver Hader2013-07-29

Actions
Related to TYPO3 Core - Bug #44105: Image size does not get updatedClosed2012-12-19

Actions
Related to TYPO3 Core - Bug #51698: Delete sys_file entry when a file is deletedClosed2013-09-03

Actions
Actions #1

Updated by Oliver Hader over 10 years ago

See attached stack-trace for details...

Actions #2

Updated by Philipp Gampe over 10 years ago

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

@Oli are you working on this?

Actions #3

Updated by Hans-Joachim Reinecke over 10 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!

Actions #4

Updated by Oliver Hader over 10 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)

Actions #5

Updated by Oliver Hader over 10 years ago

  • Status changed from Accepted to On Hold
Actions #6

Updated by Ernesto Baschny over 10 years ago

  • Is Regression set to Yes
Actions #7

Updated by Ernesto Baschny over 10 years ago

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

Updated by Tobias Pierschel over 10 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.

Actions #9

Updated by Oliver Hader over 10 years ago

  • Status changed from On Hold to Accepted
Actions #10

Updated by Ernesto Baschny over 10 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?

Actions #11

Updated by Markus Klein almost 10 years ago

Is this still an issue on 6.2?

Actions #12

Updated by Sebastian Fischer almost 10 years ago

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

Actions #13

Updated by Helmut Hummel almost 10 years ago

  • Status changed from Accepted to Resolved

sys_file does not have a deleted field any more

Actions #14

Updated by David Bruchmann over 9 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.

Actions #15

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF