Nilmoni Deb <[email protected]> writes:
> On 30 Sep 2001, Eric W. Biederman wrote:
>
> > Jim Meyering <[email protected]> writes:
> >
> > > Nilmoni Deb <[email protected]> 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 [email protected]
> > >
> > > 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.
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.
Eric
On 1 Oct 2001, Eric W. Biederman wrote:
> Nilmoni Deb <[email protected]> writes:
>
> > On 30 Sep 2001, Eric W. Biederman wrote:
> >
> > > Jim Meyering <[email protected]> writes:
> > >
> > > > Nilmoni Deb <[email protected]> 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 [email protected]
> > > >
> > > > 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
>
>
Nilmoni Deb <[email protected]> writes:
> On 1 Oct 2001, Eric W. Biederman wrote:
>
> > 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.
You add a mv -p option to do it for you.
> > 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.
O.k. So nothing breaks and we just have a suprising change to more
correct behavior. Given that I don't see the case for making a special
case in the code.
Eric
> > > 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.
Bob
Bob Proulx writes:
> 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.
Compaq Tru64 5 No time change in any case.
On Thu, 4 Oct 2001, Albert D. Cahalan wrote:
> Bob Proulx writes:
>
> > 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.
>
> Compaq Tru64 5 No time change in any case.
>
I tested it on Solaris 2.7 . No time stamp change in any of these two
cases ->
mv tmp tmp1
mv tmp ..
In the 1st case there is no justification for time change bcos even the ..
link inside the dir has not changed. In the 2nd case, there may be some
justification but it will lead to a lot of confusion. When there is
nothing to gain and something to lose why make such a change from
traditional behavior ?
thanks
- Nil