From: Tyler Hicks <code@tyhicks.com>
To: "Frank Hsiao 蕭法宣" <frankhsiao@qnap.com>,
"Bert Wesarg" <bert.wesarg@googlemail.com>
Cc: "ecryptfs@vger.kernel.org" <ecryptfs@vger.kernel.org>
Subject: Re: [PATCH] ecryptfs: set s_time_gran to get correct time granularity
Date: Thu, 26 Mar 2026 00:10:46 -0500 [thread overview]
Message-ID: <acS_1gS8HmnUFZ4A@yaupon> (raw)
In-Reply-To: <SEZPR04MB6972A94B302FC6AC528823FAB7EE2@SEZPR04MB6972.apcprd04.prod.outlook.com>
On 2024-05-17 10:09:55, Frank Hsiao 蕭法宣 wrote:
> related to: https://bugs.launchpad.net/ecryptfs/+bug/1890486
>
> This bug happens in the two following situations:
> cp -p: copy a file and preserve its atime and mtime
> touch -r: touch a file and use a ref file's time instead of current time
>
> In fs/attr.c notify_change(), atime and mtime is truncated by timestamp_truncate(),
> ecryptfs gets wrong s_time_gran (10^9 instead of original fs time granularity) and
> truncates a/mtime to whole second. Setting s_time_gran when mounting ecryptfs
> solves the issue.
Thank you! This has been applied to the next branch of the
tyhicks/ecryptfs.git tree.
I apologize that this fix was forgotten for so long. Thanks to Bert for
raising it back up to my attention.
Given the long delay since you've sent this patch, I went ahead and
slightly modified the commit message to make it follow the guidelines
documented in the Documentation/process/submitting-patches.rst file. Let
me know if you have any objections:
===
ecryptfs: Set s_time_gran to get correct time granularity
Set the eCryptfs superblock time granularity, using the lower
filesystem's s_time_gran value, to prevent unnecessary inode timestamp
truncation to the granularity of a full second.
The use of utimensat(2) to set a timestamp with nanosecond precision
would trigger this bug. That occurred when using the following utilities
to update timestamps of a file:
* cp -p: copy a file and preserve its atime and mtime
* touch -r: touch a file and use a reference file's timestamps
Closes: https://bugs.launchpad.net/ecryptfs/+bug/1890486
Signed-off-by: Frank Hsiao 蕭法宣 <frankhsiao@qnap.com>
[tyhicks: Partially rewrite the commit message]
Signed-off-by: Tyler Hicks <code@tyhicks.com>
===
You can find a direct link below but please be aware that the commit hash is
unstable and, therefore, the URL may not be valid in the future.
[1/1] ecryptfs: Set s_time_gran to get correct time granularity
https://git.kernel.org/tyhicks/ecryptfs/c/7d9ebf33d85317f3f258c627de51701e2bf7642d
Tyler
prev parent reply other threads:[~2026-03-26 5:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-17 10:09 [PATCH] ecryptfs: set s_time_gran to get correct time granularity Frank Hsiao 蕭法宣
2024-12-06 12:29 ` Bert Wesarg
2026-02-23 19:11 ` Bert Wesarg
2025-01-08 6:56 ` 回覆: " Frank Hsiao 蕭法宣
2026-03-26 5:10 ` Tyler Hicks [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acS_1gS8HmnUFZ4A@yaupon \
--to=code@tyhicks.com \
--cc=bert.wesarg@googlemail.com \
--cc=ecryptfs@vger.kernel.org \
--cc=frankhsiao@qnap.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox