Received: by 2002:a19:f614:0:0:0:0:0 with SMTP id x20csp56591lfe; Fri, 15 Apr 2022 19:17:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwrPjkTTRQhLuOtzy6bT7c+T1Uoozdk8Na+IHznJCDRQqEmhizd8wqzwg+209UO4dvCQupK X-Received: by 2002:a17:90b:390c:b0:1d0:9963:6eb8 with SMTP id ob12-20020a17090b390c00b001d099636eb8mr6849002pjb.59.1650075461124; Fri, 15 Apr 2022 19:17:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650075461; cv=none; d=google.com; s=arc-20160816; b=XBWCzQpfLuO3zGnju6rZ1GOVBjV67GoZVyCq18Y1gD6FMG6NeT7oeypNwodr5EdOG9 E5z4M5iXZ4N03z+bOCi3A75SV4yuY1oextYPRb+c8CIxNWx4bmRSHBNjaFdvCXDbrjt6 5Aw9Z4FIntiOjAjM/3zwGw2unWDZBOjkCZCQ+c1DcX3wHO2SStdfbuZfC4eqkzNpAwIg 9FxhOGGgd8WPiNS0evhDc+/h3ggGajJs81WQ1mbsLxmjkiodjXalWCPk+RvbEI44/Uat YGo2bPZq94T8maePnTgeFSDhcWMf+fU9IdaSKGHC8TjZHn10Ur4EcpjEUwX2S1GVqiXh NXqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:in-reply-to :date:references:subject:cc:to:from; bh=u3gCvKRm5oxW7W42BOLaCC9jQrNiyrRu3gMAByuDUCM=; b=O0I5fumlykaJmsycdvDZrIwoga3botq1DB/kP0FOgtpSrMOu32X0R3+M5tz4JUw8Xt ZtRA0ZNrlSEmX/y1xBv4F6UXTDmJpfWHOKOsUIP7x540m1A4VD0XLqSQaRwCe5y0U/cn E+D+LQnJvKFJFI6uADzOxQLiafVK43IEyu6Py4uuJoaAZt9wPxUm039woWutDWF7m34g ZMxgjWkYu9PeAr2NV6RlxU6/q+wcjxXLOM7fwvAyaaPlLPZNVuf6Ys2nbfchnhEnI2zr SxPBpopjOzSTNZ47pg++LFf/wBT7TSK8ScK5oor6ZN5bh386ceAwqMaR9t3iSia2/Jp8 6n0A== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id c11-20020a170902aa4b00b00153b2d164e1si2728921plr.233.2022.04.15.19.17.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 19:17:41 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4FEB7939BF; Fri, 15 Apr 2022 18:33:06 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353979AbiDONak (ORCPT + 99 others); Fri, 15 Apr 2022 09:30:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39502 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229982AbiDONai (ORCPT ); Fri, 15 Apr 2022 09:30:38 -0400 Received: from mail.parknet.co.jp (mail.parknet.co.jp [210.171.160.6]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CDC495C37E for ; Fri, 15 Apr 2022 06:28:10 -0700 (PDT) Received: from ibmpc.myhome.or.jp (server.parknet.ne.jp [210.171.168.39]) by mail.parknet.co.jp (Postfix) with ESMTPSA id 5436915F939; Fri, 15 Apr 2022 22:28:10 +0900 (JST) Received: from devron.myhome.or.jp (foobar@devron.myhome.or.jp [192.168.0.3]) by ibmpc.myhome.or.jp (8.16.1/8.16.1/Debian-3) with ESMTPS id 23FDS9K7063447 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 15 Apr 2022 22:28:10 +0900 Received: from devron.myhome.or.jp (foobar@localhost [127.0.0.1]) by devron.myhome.or.jp (8.16.1/8.16.1/Debian-3) with ESMTPS id 23FDS9jn130716 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 15 Apr 2022 22:28:09 +0900 Received: (from hirofumi@localhost) by devron.myhome.or.jp (8.16.1/8.16.1/Submit) id 23FDS8fs130713; Fri, 15 Apr 2022 22:28:08 +0900 From: OGAWA Hirofumi To: Chung-Chiang Cheng Cc: linux-kernel@vger.kernel.org, kernel@cccheng.net, shepjeng@gmail.com Subject: Re: [PATCH v3 2/3] fat: make ctime and mtime identical explicitly References: <20220415094518.380543-1-cccheng@synology.com> <20220415094518.380543-2-cccheng@synology.com> Date: Fri, 15 Apr 2022 22:28:08 +0900 In-Reply-To: <20220415094518.380543-2-cccheng@synology.com> (Chung-Chiang Cheng's message of "Fri, 15 Apr 2022 17:45:17 +0800") Message-ID: <87czhitr13.fsf@mail.parknet.co.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Chung-Chiang Cheng writes: > - fat_truncate_time(dir, NULL, S_ATIME|S_MTIME); > + fat_truncate_time(dir, NULL, S_ATIME|S_CTIME|S_MTIME); fat_truncate_time() updates i_ctime too. So S_CTIME should not be necessary here. And I think this is better to use only S_MTIME to tell this is the point of mtime update. (And, in fat_truncate_time(), I think S_CTIME is not required, because we ignore ctime change, isn't it?) Or you are going to update mtime on rename, etc too? > + /* > + * ctime and mtime share the same on-disk field, and should be > + * identical in memory. > + */ > + if (flags & (S_CTIME|S_MTIME)) { > fat_truncate_mtime(sbi, now, &inode->i_mtime); > + inode->i_ctime = inode->i_mtime; > + } [...] > clear_nlink(inode); > - fat_truncate_time(inode, NULL, S_CTIME); > + fat_truncate_time(inode, NULL, S_CTIME|S_MTIME); This is the point to update ctime. You want to affect ctime change to mtime? As I said in previous post, I think we are better to ignore ctime change, because it may become yet another incompatible behavior. > fat_detach(inode); > out: > mutex_unlock(&MSDOS_SB(sb)->s_lock); > @@ -415,7 +415,7 @@ static int msdos_unlink(struct inode *dir, struct dentry *dentry) > if (err) > goto out; > clear_nlink(inode); > - fat_truncate_time(inode, NULL, S_CTIME); > + fat_truncate_time(inode, NULL, S_CTIME|S_MTIME); ditto > fat_detach(inode); > out: > mutex_unlock(&MSDOS_SB(sb)->s_lock); > @@ -550,7 +550,7 @@ static int do_msdos_rename(struct inode *old_dir, unsigned char *old_name, > drop_nlink(new_inode); > if (is_dir) > drop_nlink(new_inode); > - fat_truncate_time(new_inode, &ts, S_CTIME); > + fat_truncate_time(new_inode, &ts, S_CTIME|S_MTIME); ditto > } > out: [...] > @@ -981,7 +981,7 @@ static int vfat_rename(struct user_namespace *mnt_userns, struct inode *old_dir, > drop_nlink(new_inode); > if (is_dir) > drop_nlink(new_inode); > - fat_truncate_time(new_inode, &ts, S_CTIME); > + fat_truncate_time(new_inode, &ts, S_CTIME|S_MTIME); ditto Thanks. -- OGAWA Hirofumi