Bug #50508
Re-uploading file in backend fails
| Status: | Resolved | Start date: | 2013-07-29 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | File Abstraction Layer (FAL) | Spent time: | - | |
| Target version: | - | |||
| TYPO3 Version: | 6.2 | Is Regression: | Yes | |
| PHP Version: | 5.3 | Sprint Focus: | ||
| Complexity: | medium |
Description
- 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
(11 kB)
Related issues
History
#1 Updated by Oliver Hader about 2 years ago
- File 50508.html added
See attached stack-trace for details...
#2 Updated by Philipp Gampe about 2 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 2 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 2 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 2 years ago
- Status changed from Accepted to On Hold
#6 Updated by Ernesto Baschny almost 2 years ago
- Is Regression set to Yes
#7 Updated by Ernesto Baschny almost 2 years ago
- Category changed from 1394 to File Abstraction Layer (FAL)
#8 Updated by Tobias Pierschel almost 2 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 almost 2 years ago
- Status changed from On Hold to Accepted
#10 Updated by Ernesto Baschny almost 2 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 1 year ago
Is this still an issue on 6.2?
#12 Updated by Sebastian Fischer about 1 year 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 about 1 year ago
- Status changed from Accepted to Resolved
sys_file does not have a deleted field any more
#14 Updated by David Bruchmann about 1 year 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.