lkml.org 
[lkml]   [2001]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: fs/ext2/namei.c: dir link/unlink bug? [Re: mv changes dir timestamp


On 1 Oct 2001, Eric W. Biederman wrote:

> Nilmoni Deb <ndeb@ece.cmu.edu> writes:
>
> > On 30 Sep 2001, Eric W. Biederman wrote:
> >
> > > Jim Meyering <jim@meyering.net> writes:
> > >
> > > > Nilmoni Deb <ndeb@ece.cmu.edu> wrote:
> > > > > When I move a directory its time stamp gets changed.
> > > > > I am using mv version 4.1 (with mandrake-8.1).
> > > >
> > > > Thanks a lot for reporting that!
> > > > This appears to be a bug not in GNU mv, nor even in GNU libc, but
> > > > rather in the underlying implementation in the kernel ext2 file system
> > > > support. The offending change seems to have come in with a rewrite
> > > > of fs/ext2/namei.c that happened sometime between 2.4.4 and 2.4.9.
> > > >
> > > > That file begins with this new comment:
> > > >
> > > > * Rewrite to pagecache. Almost all code had been changed, so blame me
> > > > * if the things go wrong. Please, send bug reports to viro@math.psu.edu
> > > >
> > > > This demonstrates that the problem affects ext2, but not tmpfs
> > > > using a 2.4.10 kernel (notice that the timestamp doesn't change
> > > > in /t, but does in the ext2 /tmp):
> > >
> > > 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?
> >
> > We are used to the preservation of time stamps during a dir move
> > (both inside and outside its parent dir) in other working kernels such as
> > 2.2.x and 2.4.2 and 2.4.3. After all, dir time-stamp lets us know when
> > directory contents have been last changed.
>
> The contents of the .. directory entry where changed in the move.
> This is why I don't see the immediate problem. I see the difference
> but I don't see the problem.
>
> > In fact even "cp -p" allows
> > the user to preserve the time stamp during dir copy. With the current
> > implementation of mv the user will not have the option of preserving the
> > time-stamp during a dir move. In any case, if we want to change the time
> > stamp of a dir we always have the option of using touch.
>
> Or vice versa, as touch will also go back in time.

This is not a good idea because once the user has to remember the exact
time stamp before the move and put that on the moved dir using touch.

>
> 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.

U r right but most users won't care too much about the ".." link inside
each dir. Its the other files that really count. If the other files
remain unchanged then they consider the dir as unchanged.

thanks
- Nil

>
> Eric
>
>

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:03    [W:0.092 / U:10.948 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site