starred/s3fs-fuse

Fork 0

mirror of https://github.com/s3fs-fuse/s3fs-fuse.git synced 2026-04-25 21:35:58 +03:00

[GH-ISSUE #1454] test_update_time and test_update_directory_time fail due to access time #765

New issue

Closed

opened 2026-03-04 01:48:35 +03:00 by kerem · 4 comments

kerem commented

2026-03-04 01:48:35 +03:00

Owner

Originally created by @gaul on GitHub (Oct 16, 2020).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1454

I see this consistently on my Linux system:

touch with -a option expected updated ctime: 1602857824 != 1602857824, atime: 1602857824 != 1602857824 and same mtime: 1602857824 == 1602857824

I wonder why we don't see this in Travis? Likely a regression from #1437.

Originally created by @gaul on GitHub (Oct 16, 2020). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1454 I see this consistently on my Linux system: ``` touch with -a option expected updated ctime: 1602857824 != 1602857824, atime: 1602857824 != 1602857824 and same mtime: 1602857824 == 1602857824 ``` I wonder why we don't see this in Travis? Likely a regression from #1437.

kerem closed this issue

2026-03-04 01:48:35 +03:00

kerem commented

2026-03-04 01:48:36 +03:00

Author

Owner

@ggtakec commented on GitHub (Oct 17, 2020):

The s3fs entry point called by the touch command is the s3fs_utimens() function.
Then the value of mtime/ctime/atime are passed to the argument timespec [2] of this function.

The processing inside the s3fs_utimens() function differs depending on whether the file is opened or not.
If you were running the s3fs test script, you probably haven't opened the file.
In this case, merge_headers() sets each header, and then put_headers() is called, which is a simple process.

I think from this error:
It is highly possible that ts[0].tv_sec of the argument timespec[2] of the s3fs_utimens() function is the same as atime/ctime of the file before executing the touch command.
If you are logging, you can look for the line like below.

[INF] s3fs.cpp:s3fs_utimens(1925): [path=/zzz][mtime=1601651879][ctime/atime=1602901289]

I think that if the atime/ctime value in this log is the same as the atime/ctime value set in the file, then the defect does not seem to be s3fs.
In other words, there seems to be a problem up to the call from fuse.
The test program waits 2 seconds before executing the touch command, so basically I don't think this will happen.
It's a mystery.

@ggtakec commented on GitHub (Oct 17, 2020): The s3fs entry point called by the touch command is `the s3fs_utimens()` function. Then the value of `mtime`/`ctime`/`atime` are passed to the argument timespec [2] of this function. The processing inside the `s3fs_utimens()` function differs depending on whether the file is opened or not. If you were running the s3fs test script, you probably haven't opened the file. In this case, `merge_headers()` sets each header, and then `put_headers()` is called, which is a simple process. I think from this error: It is highly possible that `ts[0].tv_sec` of the argument `timespec[2]` of the `s3fs_utimens()` function is the same as `atime`/`ctime` of the file before executing the touch command. If you are logging, you can look for the line like below. ``` [INF] s3fs.cpp:s3fs_utimens(1925): [path=/zzz][mtime=1601651879][ctime/atime=1602901289] ``` I think that if the `atime`/`ctime` value in this log is the same as the `atime`/`ctime` value set in the file, then the defect does not seem to be s3fs. In other words, there seems to be a problem up to the call from fuse. The test program waits 2 seconds before executing the touch command, so basically I don't think this will happen. It's a mystery.

kerem commented

2026-03-04 01:48:36 +03:00

Author

Owner

@gaul commented on GitHub (Oct 17, 2020):

I reproduced these symptoms on both my Fedora 32 desktop and Debian 10 Raspberry Pi:

s3fs: [INF] s3fs.cpp:s3fs_utimens(1925): [path=/testrun-21107/test-s3fs.txt][mtime=1602905290][ctime/atime=1602905290]
...
touch with -a option expected updated ctime: 1602905290 != 1602905290, atime: 1602905290 != 1602905290 and same mtime: 1602905290 == 1602905290

@gaul commented on GitHub (Oct 17, 2020): I reproduced these symptoms on both my Fedora 32 desktop and Debian 10 Raspberry Pi: ``` s3fs: [INF] s3fs.cpp:s3fs_utimens(1925): [path=/testrun-21107/test-s3fs.txt][mtime=1602905290][ctime/atime=1602905290] ... touch with -a option expected updated ctime: 1602905290 != 1602905290, atime: 1602905290 != 1602905290 and same mtime: 1602905290 == 1602905290 ```

kerem commented

2026-03-04 01:48:36 +03:00

Author

Owner

@ggtakec commented on GitHub (Oct 17, 2020):

It seems that s3fs_utimens is called with this error value as an argument.
That means that as the logic in s3fs, each value is set correctly.
We need to find out why the function was called with this value.

Will the results change when you run the touch(-a) command manually or when you increase the sleep seconds in the test_update_time test?

In integration-test-main.sh, there is a test for the touch command before touch -a.
Considering that this test is SUCCESS, there may be something different only with the touch -a command in these environments.

@ggtakec commented on GitHub (Oct 17, 2020): It seems that `s3fs_utimens` is called with this error value as an argument. That means that as the logic in s3fs, each value is set correctly. We need to find out why the function was called with this value. Will the results change when you run the touch(-a) command manually or when you increase the sleep seconds in the test_update_time test? In integration-test-main.sh, there is a test for the `touch` command before` touch -a`. Considering that this test is SUCCESS, there may be something different only with the `touch -a` command in these environments.

kerem commented

2026-03-04 01:48:36 +03:00

Author

Owner

@ggtakec commented on GitHub (Nov 18, 2020):

@gaul
I was able to reproduce this problem.
The cause cannot be clearly explained, but it will be explained below.

First, when this problem happens, the s3fs_utimens() entry function is not called from the FUSE library.
Therefore, the test(the result of the touch -a command) has failed while retaining the previous value.

I have confirmed that this test works correctly on macos10 and ubuntu:xenial and fails on ubuntu:bionic and focal.

About the cause, I think it's probably due to the state(option) of the mount.(ex. relatime/noatime values that can be confirmed with the mount command, etc.)
However, there are still some things I don't understand.
It doesn't fail the test even though the relatime option is set to ubuntu:xenial.

We may need to know more about mount and atime update options(strictatime/lazytime/relatime, etc).

However, we want to get out of the situation where the test may fail now, so I will post a PR to bypass this test later.

@ggtakec commented on GitHub (Nov 18, 2020): @gaul I was able to reproduce this problem. The cause cannot be clearly explained, but it will be explained below. First, when this problem happens, the s3fs_utimens() entry function is not called from the FUSE library. Therefore, the test(the result of the `touch -a` command) has failed while retaining the previous value. I have confirmed that this test works correctly on macos10 and ubuntu:xenial and fails on ubuntu:bionic and focal. About the cause, I think it's probably due to the state(option) of the mount.(ex. relatime/noatime values that can be confirmed with the mount command, etc.) However, there are still some things I don't understand. It doesn't fail the test even though the relatime option is set to ubuntu:xenial. We may need to know more about mount and atime update options(strictatime/lazytime/relatime, etc). However, we want to get out of the situation where the test may fail now, so I will post a PR to bypass this test later.

kerem referenced this issue

2026-03-04 02:01:25 +03:00

[PR #765] [MERGED] Add Debian installation instructions #1633