[PR #2091] [MERGED] Fixed renaming bug with SSE #2334

New issue

Closed

opened 2026-03-04 02:04:59 +03:00 by kerem · 0 comments

kerem commented

2026-03-04 02:04:59 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/s3fs-fuse/s3fs-fuse/pull/2091
Author: @ggtakec
Created: 1/8/2023
Status: ✅ Merged
Merged: 1/9/2023
Merged by: @gaul

Base: master ← Head: fix_sse_rename

📝 Commits (1)

92f3987 Fixed renaming bug with SSE

📊 Changes

3 files changed (+68 additions, -74 deletions)

View changed files

📝 src/curl.cpp (+39 -57)
📝 src/curl.h (+1 -1)
📝 src/s3fs.cpp (+28 -16)

📄 Description

Relevant Issue (if applicable)

#2089 #2088

Details

There was a bug that failed to rename files using SSE due to omission of #2088 fix. (for #2089)

In the SSE compatible specifications, some specifications were unclear and they were bugs, so I fixed them.
There are no basic specification changes, but we have clarified the parts that were not clear so far, fixed them, and tested all of them.

Also, there was a cache problem in rename(if the cache file did not exist when renaming), so it has been fixed.
Please allow me to submit this fix in this PR as it was required for testing.(s3fs.cpp)

For reference, the clear specifications around SSE are summarized below.

File creation(uploading)

Depending on the s3fs boot options, the encryption shown below will be used.

s3fs option	Encryption type
No option specified for encryption	not encrypted
use_sse	SSE-S3
use_sse=custom(c)	SSE-C
use_sse=kmsid	SSE-KMS

These are independent of the options below related to s3fs upload types.
nomultipart, nomixupload, streamupload, nocopyapi, norenameapi, or do not specify the option on the left(this is default: mix upload)

I've been testing a combination of these options prior to this PR. (Since it is not automated, I checked it at hand.)

Rename, etc(when modifying an existing object)

This is when user changes an existing object and upload it again(or change it with the COPY API), such as rename.

In this case, the s3fs process encryption type(boot option) at the time of operation determines the upload object encryption.
The encryption type of the source object does not affect the encryption type of the uploaded object.

s3fs option ==> Source file encryption	not encrypted	SSE-S3	SSE-C(current key)	SSE-C(old key)	SSE-KMS
not encrypted	not encrypted	SSE-S3	SSE-C(current key)	SSE-C(old key)	SSE-KMS
SSE-S3	not encrypted	SSE-S3	SSE-C(current key)	SSE-C(old key)	SSE-KMS
SSE-C(current key)	-	-	SSE-C(current key)	-	-
SSE-C(old key)	-	-	SSE-C(current key)	SSE-C(old key)	-
SSE-KMS	not encrypted	SSE-S3	SSE-C(current key)	SSE-C(old key)	SSE-KMS

SSE-C in s3fs allows user to have multiple keys.
However, only one of them(first item) is used for uploading, and the rest are used only for decryption.
This is so that if you change the key, you can still read using the old key.

In the table above, SSE-C(current key) indicates this encryption key, and SSE-C(old key) indicates the previous generation key.
In the s3fs option in the above table column, the part that is SSE-C (current key) is the case where the key to be encrypted at startup (current key) and the previous generation key (old key) are passed together.
SSE-C (old key) in s3fs option is a case where only the previous generation key (old key) is passed at startup and this previous generation key (old key) is used for encryption and decryption.(i.e. don't know the current key)

In the specification, if the object can be loaded(there are cases where access is not possible depending on the encryption format of the object), the object will be uploaded with the encryption SSE type specified at s3fs startup.
Upload operation is not possible if access is not possible due to the encryption method of the object.

I tested the above specs with nomultipart, nomixupload, streamupload, nocopyapi, norenameapi, do not specify the option on the left(this is default: mix upload) options for each upload.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/s3fs-fuse/s3fs-fuse/pull/2091 **Author:** [@ggtakec](https://github.com/ggtakec) **Created:** 1/8/2023 **Status:** ✅ Merged **Merged:** 1/9/2023 **Merged by:** [@gaul](https://github.com/gaul) **Base:** `master` ← **Head:** `fix_sse_rename` --- ### 📝 Commits (1) - [`92f3987`](https://github.com/s3fs-fuse/s3fs-fuse/commit/92f3987db0727af27e741ea86af3c3f308990783) Fixed renaming bug with SSE ### 📊 Changes **3 files changed** (+68 additions, -74 deletions) <details> <summary>View changed files</summary> 📝 `src/curl.cpp` (+39 -57) 📝 `src/curl.h` (+1 -1) 📝 `src/s3fs.cpp` (+28 -16) </details> ### 📄 Description ### Relevant Issue (if applicable) #2089 #2088 ### Details There was a bug that failed to rename files using SSE due to omission of #2088 fix. (for #2089) In the SSE compatible specifications, some specifications were unclear and they were bugs, so I fixed them. There are no basic specification changes, but we have clarified the parts that were not clear so far, fixed them, and tested all of them. Also, there was a cache problem in rename(if the cache file did not exist when renaming), so it has been fixed. Please allow me to submit this fix in this PR as it was required for testing.(s3fs.cpp) For reference, the clear specifications around SSE are summarized below. #### File creation(uploading) Depending on the s3fs boot options, the encryption shown below will be used. | s3fs option | Encryption type | | ---------------------------------- | --------------- | | No option specified for encryption | not encrypted | | use_sse | SSE-S3 | | use_sse=custom(c) | SSE-C | | use_sse=kmsid | SSE-KMS | These are independent of the options below related to s3fs upload types. `nomultipart`, `nomixupload`, `streamupload`, `nocopyapi`, `norenameapi`, or do not specify the option on the left(this is default: `mix upload`) I've been testing a combination of these options prior to this PR. (Since it is not automated, I checked it at hand.) #### Rename, etc(when modifying an existing object) This is when user changes an existing object and upload it again(or change it with the `COPY API`), such as rename. In this case, the s3fs process encryption type(boot option) at the time of operation determines the upload object encryption. The encryption type of the source object does not affect the encryption type of the uploaded object. | s3fs option ==> Source file encryption | not encrypted   | SSE-S3   | SSE-C(current key)   | SSE-C(old key)   | SSE-KMS   | | ------------------------------------------ | ------------------------ | ---------------- | ---------------------------- | ------------------------ | ----------------- | | not encrypted | not encrypted | SSE-S3 | SSE-C(current key) | SSE-C(old key) | SSE-KMS | | SSE-S3 | not encrypted | SSE-S3 | SSE-C(current key) | SSE-C(old key) | SSE-KMS | | SSE-C(current key) | - | - | SSE-C(current key) | - | - | | SSE-C(old key) | - | - | SSE-C(current key) | SSE-C(old key) | - | | SSE-KMS | not encrypted | SSE-S3 | SSE-C(current key) | SSE-C(old key) | SSE-KMS | SSE-C in s3fs allows user to have multiple keys. However, only one of them(first item) is used for uploading, and the rest are used only for decryption. _This is so that if you change the key, you can still read using the old key._ In the table above, SSE-C(current key) indicates this encryption key, and SSE-C(old key) indicates the previous generation key. In the s3fs option in the above table column, the part that is SSE-C (current key) is the case where the key to be encrypted at startup (current key) and the previous generation key (old key) are passed together. SSE-C (old key) in s3fs option is a case where only the previous generation key (old key) is passed at startup and this previous generation key (old key) is used for encryption and decryption.(i.e. don't know the current key) In the specification, if the object can be loaded(there are cases where access is not possible depending on the encryption format of the object), the object will be uploaded with the encryption SSE type specified at s3fs startup. Upload operation is not possible if access is not possible due to the encryption method of the object. I tested the above specs with `nomultipart`, `nomixupload`, `streamupload`, `nocopyapi`, `norenameapi`, do not specify the option on the left(this is default: `mix upload`) options for each upload. --- 🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.