- Issue created by @whiz11
- 🇺🇸United States cmlara
At the moment this seems more “works as designed” than a bug.
Perhaps we should have a task to document this as a limitation in the streamWrapper.
The provided workaround unfortunately is not a solution that is viable for us to implement, a caller will expect they can both read and write to the full file when they will only be able to write. See https://www.php.net/manual/en/function.fopen.php. I’m not sure if the caller in your example did not need to read the file at all (in which case they are requesting excessive access) or if it that because it’s a new file written from scratch the SDK write buffer has all the information and only after fully writing is the caller attempting to read. In either case its operation is undefined with regards to the API usage.
Glancing at the SDK it is basically a read or write concept in the code, it doesn’t really have a concept of “read + write” https://github.com/aws/aws-sdk-php/blob/63c720229a9c9cdedff6bac98d6e72be... which makes sense when you consider the file doesn’t exist on S3 until it’s flushed and it doesn’t exist locally until it’s read.
I can also suggest a possible alternative is to consider extracting the files to a temporary location (“temporary://“ or FileSystemInterface::getTempDirectory) and once extracted recursively copy them to s3://.
In theory it might be possible for the SDK to add w+ support though it would certainly have performance impacts compared to the current system. This would be better as a feature request for the AWS SDK.
- Issue was unassigned.