[lkml]   [2001]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: fs/ext2/namei.c: dir link/unlink bug? [Re: mv changes dir timestamp
    > > > This actually looks like a fix.  Ext2 keeps a directory entry
    > > > named .. in the directory so it knows what the parent directory
    > > > is. So to rename a directory besides it must unlink(..) and the
    > > > link(..) inside the directory being moved, at least logically.
    > > > In the case you gave as the parent directory didn't change it
    > > > could be optimized out, but it probably isn't worth it.
    > > > I know this is different but why is this a problem?
    > My question is which semantics are desirable, and why. I conceed
    > that something has changed. And that changing the functionality back
    > to the way it was before may be desireable. But given that the
    > directory is in fact changed my gut reaction is that the new behavior
    > is more correct than the old behavior.

    I would preserve the timestamp for these reasons.

    1. Changing the timestamp is counter-intuitive. Over time many people
    will be surprised by this behavior. It is less surprising to
    preserve the timestamp for the cases where nothing changed.

    2. Since the .. entry did not change this variance seems gruitous.
    That is, a listing of the directory contents will not show any
    change whatsoever. So in the case that there was no real changes
    the timestamp update seems out of place.

    3. It is a common practice to use timestamp and file size to determine
    if changes have occured. It is also common to move directories
    (and files) out of the way while testing a copy of data for
    specific test purposes. I can easily construct examples where no
    changes *should* exist but this new behavior would show gratitious
    timestamp updates.
    mv foo foo.bak
    cp -a foo.bak foo
    hack on foo
    rm -rf foo
    mv foo.bak foo

    4. This new behavior is different from traditional UNIX filesystems.
    If the difference is arbitrary but neither good nor bad I would
    stick with the traditional behavior.

    I tested this on both HP-UX, IBM AIX and Linux. HP-UX always
    preserved the previous timestamps. The same with 2.2.x versions of
    Linux. AIX was different and preserved the previous timestamp if
    the .. entry was the same as before but updated the timestamp if .. was
    different than before. But in the case where no real changes occurred
    none updated the timestamp. It would be interesting to see what
    Sun's Solaris and other systems do in those cases. This does not seem
    like a huge deal. There were differences in the different commercial
    flavors. But I like to think that we can do better than that.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:04    [W:0.024 / U:13.872 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site