[PR #1254] [MERGED] Added mime option for strict checking of mime types file #1888

Closed
opened 2026-03-04 02:02:39 +03:00 by kerem · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/s3fs-fuse/s3fs-fuse/pull/1254
Author: @ggtakec
Created: 3/19/2020
Status: Merged
Merged: 4/11/2020
Merged by: @ggtakec

Base: masterHead: modify_mimetypes


📝 Commits (1)

  • 7fbda23 Added mime option for strict checking of mime types file

📊 Changes

8 files changed (+137 additions, -35 deletions)

View changed files

📝 COMPILATION.md (+5 -1)
📝 doc/man/s3fs.1 (+5 -0)
📝 src/curl.cpp (+47 -8)
📝 src/curl.h (+2 -2)
📝 src/s3fs.cpp (+30 -2)
📝 src/s3fs_util.cpp (+40 -2)
📝 src/s3fs_util.h (+2 -0)
📝 test/integration-test-main.sh (+6 -20)

📄 Description

Relevant Issue (if applicable)

#1253 #1217

Details

Background

The issue #1217 is that when s3fs cannot load the /etc/mime.types file, it uploads the Content-Type of all objects as application/octet-stream.
As pointed out in PR #1253, s3fs should not be able to build or start up.
This allows the user to notice that there is a problem with mime.types.

What this PR changed

Added mime option

Added this option so that the user can specify the mime.types file path instead of /etc/mime.types(default).
I considered that the mime.types file path may be different depending on the environment by each user.
On non-macOS, the default mime.types path is /etc/mime.types. (this path is used when this option is not specified)
On macOS after Cataline, apache2.4 is pre-installed , so /etc/apache2/mime.types is the default for macOS.
This option gives user's environment flexibility.

Exit if mime.types loading fails

s3fs exits with an error if the mime.types file(both default and user specified) fails to load.
This allows the user to know that there is problem with mime.types path.
Also, if s3fs can be started, mime.types can be loaded correctly, so it will solve #1217.

Undo test evasion

I restored the content-types test for macOS that was avoided in #1237.
The error was occurred when testing code #1242 because /etc/mime.types did not exist on macOS.
My response and fixing to #1237 was temporary and wrong.
Therefore, I restored the original test to confirm that content-types can be set correctly on macOS.


🔄 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/1254 **Author:** [@ggtakec](https://github.com/ggtakec) **Created:** 3/19/2020 **Status:** ✅ Merged **Merged:** 4/11/2020 **Merged by:** [@ggtakec](https://github.com/ggtakec) **Base:** `master` ← **Head:** `modify_mimetypes` --- ### 📝 Commits (1) - [`7fbda23`](https://github.com/s3fs-fuse/s3fs-fuse/commit/7fbda230f5de31b722a979e8780593c2504f0a89) Added mime option for strict checking of mime types file ### 📊 Changes **8 files changed** (+137 additions, -35 deletions) <details> <summary>View changed files</summary> 📝 `COMPILATION.md` (+5 -1) 📝 `doc/man/s3fs.1` (+5 -0) 📝 `src/curl.cpp` (+47 -8) 📝 `src/curl.h` (+2 -2) 📝 `src/s3fs.cpp` (+30 -2) 📝 `src/s3fs_util.cpp` (+40 -2) 📝 `src/s3fs_util.h` (+2 -0) 📝 `test/integration-test-main.sh` (+6 -20) </details> ### 📄 Description ## Relevant Issue (if applicable) #1253 #1217 ## Details ### Background The issue #1217 is that when s3fs cannot load the /etc/mime.types file, it uploads the Content-Type of all objects as application/octet-stream. As pointed out in PR #1253, s3fs should not be able to build or start up. This allows the user to notice that there is a problem with mime.types. ### What this PR changed #### Added mime option Added this option so that the user can specify the mime.types file path instead of /etc/mime.types(default). I considered that the mime.types file path may be different depending on the environment by each user. On non-macOS, the default mime.types path is /etc/mime.types. (this path is used when this option is not specified) On macOS after Cataline, apache2.4 is pre-installed , so /etc/apache2/mime.types is the default for macOS. This option gives user's environment flexibility. ### Exit if mime.types loading fails s3fs exits with an error if the mime.types file(both default and user specified) fails to load. This allows the user to know that there is problem with mime.types path. Also, if s3fs can be started, mime.types can be loaded correctly, so it will solve #1217. ### Undo test evasion I restored the content-types test for macOS that was avoided in #1237. The error was occurred when testing code #1242 because /etc/mime.types did not exist on macOS. My response and fixing to #1237 was temporary and wrong. Therefore, I restored the original test to confirm that content-types can be set correctly on macOS. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
kerem 2026-03-04 02:02:39 +03:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/s3fs-fuse#1888
No description provided.