[PR #1655] [MERGED] Additional bug fixing for not creating zero-byte object #2098

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

📋 Pull Request Information

Original PR: https://github.com/s3fs-fuse/s3fs-fuse/pull/1655
Author: @ggtakec
Created: 5/9/2021
Status: Merged
Merged: 5/9/2021
Merged by: @gaul

Base: masterHead: fix_open_stats


📝 Commits (1)

  • ced5cd2 Additional bug fixing for not creating zero-byte object

📊 Changes

3 files changed (+89 additions, -13 deletions)

View changed files

📝 src/cache.cpp (+47 -3)
📝 src/cache.h (+3 -0)
📝 src/s3fs.cpp (+39 -10)

📄 Description

Relevant Issue (if applicable)

#1640

Details

Current s3fs_create function no longer creates(does not upload) a 0-byte initial file, only adds StatCache for it.
However, there was a problem because the response to the situation that this file object on the s3 does not exist yet was insufficient.

First, StatCache has an expiration date, and if the expiration date has expired, StatCache will be deleted.
Even if it has not expired, it may be deleted by renewal or deleted directly.
When s3fs gets the information of the file, if StatCache does not exist, it tries to get the information from the real file(object on S3).
In other words, the current s3fs has a problem because the initial file(0 bytes) does not exist(is not uploaded).

Thus this PR changed the code to use the no_truncate flag to prevent automatic StatCache deletion.
(changed to specify this flag when calling AddStat of the s3fs_create function.)
And I made a fix related to this flag.

About timeout for stat cache

FUSE on macOS seems to behave differently than that on other operating systems.
First, create a new file with s3fs_create, and with that file open, write to the file.
During this write process, s3fs_access may be called. (It is unknown whether the processing time is long or it depends on the file size)

Since s3fs_access was called, s3fs checks the Stat information.
If the Stats information has expired, it will immediately discard the Stats information and try to get the file information from the S3.
And since the actual file does not exist, an error(Device not configured) will occur.
This bug occurred when I ran the test_multipart_mix test on macOS with -o dbglevel=dbg.

In addition, we have not confirmed the occurrence of the problem due to this timeout on other OS.
But if s3fs gets a similar call, it is easy to imagine same error.


🔄 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/1655 **Author:** [@ggtakec](https://github.com/ggtakec) **Created:** 5/9/2021 **Status:** ✅ Merged **Merged:** 5/9/2021 **Merged by:** [@gaul](https://github.com/gaul) **Base:** `master` ← **Head:** `fix_open_stats` --- ### 📝 Commits (1) - [`ced5cd2`](https://github.com/s3fs-fuse/s3fs-fuse/commit/ced5cd2822596346dad8fe5cb075fcb7e965f985) Additional bug fixing for not creating zero-byte object ### 📊 Changes **3 files changed** (+89 additions, -13 deletions) <details> <summary>View changed files</summary> 📝 `src/cache.cpp` (+47 -3) 📝 `src/cache.h` (+3 -0) 📝 `src/s3fs.cpp` (+39 -10) </details> ### 📄 Description ## Relevant Issue (if applicable) #1640 ## Details Current s3fs_create function no longer creates(does not upload) a 0-byte initial file, only adds StatCache for it. However, there was a problem because the response to the situation that this file object on the s3 does not exist yet was insufficient. First, StatCache has an expiration date, and if the expiration date has expired, StatCache will be deleted. Even if it has not expired, it may be deleted by renewal or deleted directly. When s3fs gets the information of the file, if StatCache does not exist, it tries to get the information from the real file(object on S3). In other words, the current s3fs has a problem because the initial file(0 bytes) does not exist(is not uploaded). Thus this PR changed the code to use the `no_truncate` flag to prevent automatic StatCache deletion. (changed to specify this flag when calling AddStat of the s3fs_create function.) And I made a fix related to this flag. ### About timeout for stat cache FUSE on macOS seems to behave differently than that on other operating systems. First, create a new file with s3fs_create, and with that file open, write to the file. During this write process, s3fs_access may be called. (It is unknown whether the processing time is long or it depends on the file size) Since s3fs_access was called, s3fs checks the Stat information. If the Stats information has expired, it will immediately discard the Stats information and try to get the file information from the S3. And since the actual file does not exist, an error(Device not configured) will occur. This bug occurred when I ran the test_multipart_mix test on macOS with `-o dbglevel=dbg`. In addition, we have not confirmed the occurrence of the problem due to this timeout on other OS. But if s3fs gets a similar call, it is easy to imagine same error. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
kerem 2026-03-04 02:03:41 +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#2098
No description provided.