Repository navigation
Conversation
| /** @var array<string, string> $metadata */ | ||
| $metadata = $response['Metadata']; | ||
| foreach ($metadata as $metadataKey => $metadataValue) { | ||
| $metaInfo[$metadataKey] ??= $metadataValue; |
There was a problem hiding this comment.
Issue: this copies any S3 metadata into TYPO3's file info, potentially adding fields that should not come from S3.
For example, $metaInfo['uid'] is not set, but $metadata['uid'] = '123'. The value gets copied and passed to TYPO3's file index. When indexing a new file, TYPO3 can then try to insert it into sys_file with uid 123, causing a duplicate-key error if that UID already exists.
We should keep custom S3 metadata separate or only copy the hash fields we actually need.
| * | ||
| * @return int The number of bytes written to the file | ||
| */ | ||
| public function setFileContents(string $fileIdentifier, string $contents): int |
There was a problem hiding this comment.
Issue: editing or replacing a file writes the new content without hash metadata. Creating a new empty file or uploading an empty file also omits it. In strict mode, TYPO3's subsequent indexing then fails because hash-sha1 is missing, even though the file has already been written to S3. We should generate and include hash metadata in all write paths, including empty files.
| 'Bucket' => $this->configuration['bucket'], | ||
| 'Key' => $fileIdentifier, | ||
| ]); | ||
| $result = $this->getMetaInfo($fileIdentifier, true); |
There was a problem hiding this comment.
Issue: getMetaInfo() catches S3 exceptions and returns null. In receive mode, hash() now returns a pseudo-hash even when HEAD fails, e.g. with AccessDenied. Previously, the exception was propagated. We should distinguish a failed request from a successful response without hash metadata
No description provided.