Re: ReiserFS patch for updating ctimes of renamed files

From: jw schultz (jw_at_pegasys.ws)
Date: 10/14/03

  • Next message: Stefano Rivoir: "Re: [BUG] ext3 bug"
    Date:	Tue, 14 Oct 2003 00:09:33 -0700
    To: linux-kernel@vger.kernel.org
    
    

    On Mon, Oct 13, 2003 at 11:25:27PM -0700, Andrew Morton wrote:
    > Hans Reiser <reiser@namesys.com> wrote:
    > >
    > > do you think schultz's arguments about why it is wrong are correct?
    > > They seem well thought out to me.
    >
    > Well given that you've renamed the file, you do want the backup program to
    > pick up the "new" file. But it'd be a pretty lame backup program which was
    > fooled by a missing ctime update.
    >
    > Yes, John has a point but we're not going to go and change all the other
    > filesystems (are we?).

    I don't know who John is but i sure hope we are not going to
    go changing how working filesystems function. It may be
    technically correct to not update ctime but that doesn't
    mean that it is incorrect to update it either. It all
    depends on the filesystem. They aren't all the same. We
    have some that don't support symlinks or hardlinks or that
    have or lack other features.

    <OT>
    There are change detections through timestamp (mtime) i am
    concerned about. As an rsync maintainer i worry about be
    extended attributes or ACLs changing with no modifiable
    timestamps being updated. And, by the way, because you
    cannot set ctime it doesn't qualify. Then there is jfs
    which i found did not update mtime when directories change
    unless the block count changes, but that might have been
    fixed already.
    </OT>

    -- 
    ________________________________________________________________
    	J.W. Schultz            Pegasystems Technologies
    	email address:		jw@pegasys.ws
    		Remember Cernan and Schmitt
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Stefano Rivoir: "Re: [BUG] ext3 bug"

    Relevant Pages

    • [Fwd: [NFS PATCH] 2.6.0-test10 Invalidate cached inode attributes after rename]
      ... relevant code there indicates this is true with other Unix filesystems ... Tar prints lots of "file changed after we read it" messages. ... Tar obtains ctime via statbefore reading the file and compares it to ... invalidation during rename() eliminates this particular scenario. ...
      (Linux-Kernel)
    • Re: [PATCH] Invalidate_inodes can be very slow
      ... > it might just save us the pain of writing the scripts ourselves. ... so that inode cache grows to its maximum ... umount these filesystems. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: should delete_inode be allowed to be called from shrink_dcache?
      ... > rmdir ../dir ... it's legitimate. ... All filesystems I'm familiar with won't have ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Squashfs without ./..
      ... and strict in what you emit" applies strongly. ... in that order with sane behavior, ... of the filesystems on the planet, even if it has to emulate them ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: I request inclusion of reiser4 in the mainline kernel
      ... >for testing ext2/ext3 filesystems, but it may not be ideal for other ... >note that the paper does takes an approving note of the fact that ... >those folks in the Reiser team who might have a persecution complex, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)