Bug #34160
Replacing/Overwriting a file could leave a stale index record
| Status: | Closed | Start date: | 2012-02-21 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | File Abstraction Layer (FAL) | Spent time: | - | |
| Target version: | - | |||
| TYPO3 Version: | 6.0 | Is Regression: | No | |
| PHP Version: | Sprint Focus: | |||
| Complexity: |
Description
Currently, when overwriting a file, we have this situation:
- When copying a file over another file, everything is fine
- When moving a file over another file, everything is fine if only one of them (or none) is indexed
- When the new file is freshly uploaded, everything is fine
So there basically is one critical case: When two index records would point to the same location after changing them (this already fails in the indexer when detecting files moved outside of TYPO3). Currently there is no logic to resolve such conflicts, but we should definitely have it.
In general, the simplest approach would be to take the most recently updated index entry and change the references to all other conflicting files to point to this uid. However, the infrastructure for these operations is still missing (e.g. in the repository)
Related issues
History
#1 Updated by Andreas Wolf over 3 years ago
- Subject changed from Replacing/Overwriting a file coule leave a stale index record to Replacing/Overwriting a file could leave a stale index record
#2 Updated by Ingmar Schlecht over 3 years ago
- Target version set to 6.0 beta1
#3 Updated by Steffen Ritter almost 3 years ago
- Target version changed from 6.0 beta1 to 6.0 beta 2
#4 Updated by Andreas Wolf over 2 years ago
- Status changed from New to Accepted
- Target version changed from 6.0 beta 2 to 6.1
#5 Updated by Andreas Wolf over 2 years ago
- Project changed from File Abstraction Layer to Core
- Target version deleted (
6.1)
#6 Updated by Andreas Wolf over 2 years ago
- Category set to File Abstraction Layer (FAL)
- Target version set to 6.1.0
- TYPO3 Version set to 6.0
#7 Updated by Steffen Ritter over 1 year ago
- Status changed from Accepted to Needs Feedback
- Assigned To deleted (
Andreas Wolf) - Target version deleted (
6.1.0) - Is Regression set to No
I don't think we will fix that in 6.1/6.0 anymore
#8 Updated by Stefan Neufeind over 1 year ago
Is that solved with 45110 for 6.2 already? If no files are duplicate in 6.2 anymore, do we need a "deduplication" upon upgrade maybe? But since we might have references to the old IDs I expect that might not be possible.
#9 Updated by Alexander Opitz 11 months ago
- Status changed from Needs Feedback to Closed
No feedback within the last 90 days => closing this issue.
If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.