Or just disable etag checking based on a configuration option, and let
the user decide?
The documentation can explain the consequences - i.e. none if encryption
used, and potential undetectable corruption if not.
That way when all etags are md5 checksums, we don't lose anything. And
when they are not, we can mount what is currently a broken FS by
disabling the check.
On 19/06/2023 21:57, Nikolaus Rath wrote:
On Jun 19 2023, Peter Marshall <[email protected]> wrote:
Could the md5 (or some other signature) of the data be stored in metadata, and
we check
that instead of the Etag on reading? I've only briefly looked at the source -
maybe an
existing header is suitable.
Yes, that is possible in principle but not currently done. We'd have to
extend the metadata format to store this checksum.
I'm just not convinced that it's worth it, since this effectively
duplicates what's already done when using encryption.
So perhaps the right answer is to disable ETag checking completely and
require encryption to be used? Or disable it when encryption is active,
so that it affects cases?
Best,
-Nikolaus
--
You received this message because you are subscribed to the Google Groups
"s3ql" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/s3ql/0f58bff2-cede-36ab-818e-061b32259a7b%40goteck.co.uk.
