Project

General

Profile

Actions

Bug #34160

closed

Replacing/Overwriting a file could leave a stale index record

Added by Andreas Wolf about 12 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2012-02-21
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.0
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

Currently, when overwriting a file, we have this situation:

  1. When copying a file over another file, everything is fine
  2. When moving a file over another file, everything is fine if only one of them (or none) is indexed
  3. 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 1 (0 open1 closed)

Blocks TYPO3 Core - Bug #45110: File is listed twice in sys_fileClosed2013-02-03

Actions
Actions #1

Updated by Andreas Wolf about 12 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
Actions #2

Updated by Ingmar Schlecht almost 12 years ago

  • Target version set to 6.0 beta1
Actions #3

Updated by Steffen Ritter over 11 years ago

  • Target version changed from 6.0 beta1 to 6.0 beta 2
Actions #4

Updated by Andreas Wolf about 11 years ago

  • Status changed from New to Accepted
  • Target version changed from 6.0 beta 2 to 6.1
Actions #5

Updated by Andreas Wolf about 11 years ago

  • Project changed from 1401 to TYPO3 Core
  • Target version deleted (6.1)
Actions #6

Updated by Andreas Wolf about 11 years ago

  • Category set to File Abstraction Layer (FAL)
  • Target version set to 6.1.0
  • TYPO3 Version set to 6.0
Actions #7

Updated by Steffen Ritter about 10 years ago

  • Status changed from Accepted to Needs Feedback
  • Assignee 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

Actions #8

Updated by Stefan Neufeind about 10 years 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.

Actions #9

Updated by Alexander Opitz over 9 years 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.

Actions

Also available in: Atom PDF