-
Notifications
You must be signed in to change notification settings - Fork 188
Description
Split from #786
Requested by @masterkain
Until 2.5.0, it was possible to run S3Mock with retainFilesOnExit=true
, stop S3Mock and then start it again to serve those objects (as long as it was not a MultipartUpload, which were always mapped in memory, with only the binaries stored on disk).
With 2.5.0, all objects are stored in a directory that does not reflect their key, since that has always been problematic (encoding and decoding the key many times over depending on the use-case is error-prone and entirely unnecessary if the key is used internally only to find the correct object UUID, and with that, the folder all data is persisted in)
While this mapping is persisted to disk, we also use the UUID to lock file system access internally, and this mapping is entirely in-memory.
While retainFilesOnExit=true
is mainly meant to help with debugging to see if all data was persisted correctly, it could be possible to refactor S3Mock yet again to read all mappings on startup and serve all object requests as if it had been running all the time.
When doing this, the Multipart mapping should be persisted to disk as well to support the on/off use-case for all APIs.