rustfs
Bug: Downloading a .blockmap file with MIME type application/gzip results in incorrect .gz file extension
Describe the bug
When clicking the download button for a file that has the MIME type application/gzip but should have the .blockmap file extension, the downloaded file's extension is incorrectly changed to .gz instead of preserving the original .blockmap extension. This misleads users and may prevent the file from being recognized correctly by its intended application, as .blockmap files have a specific purpose.
To Reproduce Steps to reproduce the behavior:
- Run
docker run -d --name rustfs-demo -p 8000:9000 -p 8001:9001 -v /srv/rustfs-demo/data:/data rustfs/rustfs:latest --address :9000 --console-enable /data. - Using the
@aws-sdk/client-s3to upload a file with the typeapplication/gzipand the extension.blockmap. - Click the download button/link.
- Saved as a
.gzfile after download.
Expected behavior Do not modify the file name.
Screenshots
Desktop (please complete the following information):
- OS: Ubuntu 24.04.2 LTS
- Browser: Microsoft Edge, Version 142.0.3595.53 (Official build) (arm64)
- Rustfs Version: 1.0.0-alpha.67
Hi @Beiluola ,
Is it normal after you unzip the compressed file?
Based on my observation, the binary data of the file is valid and intact. The issue is solely with the incorrect file extension and is unrelated to decompression.
I believe the issue stems from this file's type being application/gzip. I tested and found that if I set the file type to application/octet-streamwhen uploading via the API, the incorrect extension problem does not occur upon download.
@Beiluola
This bug has been fixed.
https://github.com/rustfs/rustfs/issues/813
This issue should be resolved in v1.0.0-alpha.71. Please update and verify.
If it works, please close the issue. Otherwise, please comment below with more logs.
https://github.com/rustfs/rustfs/releases/tag/1.0.0-alpha.71