[PR #2133] [MERGED] Fixed a bug when reading a reduced file without flushing #2349

New issue

Closed

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

kerem commented

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

Owner

📋 Pull Request Information

Original PR: https://github.com/s3fs-fuse/s3fs-fuse/pull/2133
Author: @ggtakec
Created: 3/18/2023
Status: ✅ Merged
Merged: 3/26/2023
Merged by: @ggtakec

Base: master ← Head: fix_filesize2

📝 Commits (1)

148841e Fixed a bug when reading a reduced file without flushing

📊 Changes

7 files changed (+135 additions, -8 deletions)

View changed files

📝 .gitignore (+2 -0)
📝 src/fdcache_page.cpp (+6 -0)
📝 src/metaheader.cpp (+1 -1)
📝 src/s3fs.cpp (+16 -3)
📝 test/Makefile.am (+6 -4)
📝 test/integration-test-main.sh (+23 -0)
➕ test/truncate_read_file.c (+81 -0)

📄 Description

Relevant Issue (if applicable)

#2107 #2131
This PR changed the fix method because #2131 was not enough fix.

Bug details

There was a bug in trauncate, which shrinks files.

This bug occurs under the following conditions:

Open the file and shrink the file.
After shrinking, do read before flushing(do not close or sync).

At this time, it got the old size before shrinking from the server(Content-Length) and set old size again.
So that the read data from the reduced size to the original size padded as 0x00, and read it.
When read all of file, the read size is old length before reduction.

Fixes

Changed so that when opening a file that has already been opened and resized(without flushing), it is opened as the modified file size instead of the file size on the server side.

When reading(loading) a file, there was a problem that the modifying(shrink) flag was cleared after reading even though the file was reduced.
Therefore, there was a problem that flush(upload) of file size change did not occur, so it has been fixed.

Although it is not directly related to this case, there was a bug in the number of blocks used in the stat information, so it has been corrected.

I added C source code to test the condition that caused the failure and included it in this PR.
(Because it is difficult to realize with a shell script, I wrote it in C source)

_{🔄 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/2133 **Author:** [@ggtakec](https://github.com/ggtakec) **Created:** 3/18/2023 **Status:** ✅ Merged **Merged:** 3/26/2023 **Merged by:** [@ggtakec](https://github.com/ggtakec) **Base:** `master` ← **Head:** `fix_filesize2` --- ### 📝 Commits (1) - [`148841e`](https://github.com/s3fs-fuse/s3fs-fuse/commit/148841e74a1814e35b1f06d7a3109247e8a34cd6) Fixed a bug when reading a reduced file without flushing ### 📊 Changes **7 files changed** (+135 additions, -8 deletions) <details> <summary>View changed files</summary> 📝 `.gitignore` (+2 -0) 📝 `src/fdcache_page.cpp` (+6 -0) 📝 `src/metaheader.cpp` (+1 -1) 📝 `src/s3fs.cpp` (+16 -3) 📝 `test/Makefile.am` (+6 -4) 📝 `test/integration-test-main.sh` (+23 -0) ➕ `test/truncate_read_file.c` (+81 -0) </details> ### 📄 Description ### Relevant Issue (if applicable) #2107 #2131 _This PR changed the fix method because #2131 was not enough fix._ ### Bug details There was a bug in trauncate, which shrinks files. This bug occurs under the following conditions: - Open the file and shrink the file. - After shrinking, do read before flushing(do not close or sync). At this time, it got the old size before shrinking from the server(Content-Length) and set old size again. So that the read data from the reduced size to the original size padded as 0x00, and read it. When read all of file, the read size is old length before reduction. ### Fixes Changed so that when opening a file that has already been opened and resized(without flushing), it is opened as the modified file size instead of the file size on the server side. When reading(loading) a file, there was a problem that the modifying(shrink) flag was cleared after reading even though the file was reduced. Therefore, there was a problem that flush(upload) of file size change did not occur, so it has been fixed. Although it is not directly related to this case, there was a bug in the number of blocks used in the stat information, so it has been corrected. I added C source code to test the condition that caused the failure and included it in this PR. (Because it is difficult to realize with a shell script, I wrote it in C source) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>