Actions
Bug #1074
closedundo + mv => unexpected
Status:
Closed
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:
0%
Estimated time:
Description
`undo -i' seems to track the wrong file after mv, see below.
Contents of file is correct;
`hammer history' seems correct.
#!/bin/sh
Contents of file is correct;
`hammer history' seems correct.
- sh -x undo-mv
+ mkdir /hammer/XXX.2082
+ cd /hammer/XXX.2082
+ echo XXX
+ sync
+ undo -i test
test: objid=0x00000001000186be
0x0000000100030d5f 16-Jul-2008 03:52:57
+ echo YYY
+ sync
+ undo -i test
test: objid=0x00000001000186be
0x0000000100030d5f 16-Jul-2008 03:52:57
0x0000000100030d63 16-Jul-2008 03:52:57
+ mv test test1
+ sync
+ undo -i test
test: objid=0x00000001000186be
0x0000000100030d5f 16-Jul-2008 03:52:57
0x0000000100030d63 16-Jul-2008 03:52:57
+ undo -i test1
+ echo ZZZ
+ sync
+ undo -i test
test: objid=0x00000001000186be
0x0000000100030d5f 16-Jul-2008 03:52:57
0x0000000100030d63 16-Jul-2008 03:52:57
0x0000000100030d69 16-Jul-2008 03:52:58
+ undo -i test1
+ mv test1 test
+ sync
+ undo -i test
test: objid=0x00000001000186be
0x0000000100030d5f 16-Jul-2008 03:52:57
0x0000000100030d63 16-Jul-2008 03:52:57
0x0000000100030d69 16-Jul-2008 03:52:58
+ undo -i test1
+ echo WWW
+ sync
+ undo -i test
+ undo -i test1
test1: objid=0x00000001000186be
0x0000000100030d5f 16-Jul-2008 03:52:57
0x0000000100030d63 16-Jul-2008 03:52:57
0x0000000100030d69 16-Jul-2008 03:52:58
0x0000000100030d6f 16-Jul-2008 03:52:58
thomas
- undo-mv#!/bin/sh
- undo + mv => unexpected
mkdir /hammer/XXX.$$
cd /hammer/XXX.$$
echo XXX >>test
sync
undo -i test
echo YYY >>test
sync
undo -i test
mv test test1
sync
undo -i test
undo -i test1
echo ZZZ >>test1
sync
undo -i test
undo -i test1
mv test1 test
sync
undo -i test
undo -i test1
echo WWW >>test
sync
undo -i test
undo -i test1
Updated by dillon over 16 years ago
:`undo -i' seems to track the wrong file after mv, see below.
:Contents of file is correct;
:`hammer history' seems correct.
:
: -thomas
You're saying it should dump the history if either test or test1
is specified, but it only seems to do it for one of the two?
Interesting. I'll look into it. It should be able to figure out
the history for both of them. It kinda looks like the directory
entry is not being completely synced by the sync command.
Also, 'hammer synctid' doesn't work (I tried to use it instead of
sync). I'll fix that too. Another bug related to the mirroring
work.
-Matt
Updated by dillon over 16 years ago
:`undo -i' seems to track the wrong file after mv, see below.
:Contents of file is correct;
:`hammer history' seems correct.
:
: -thomas
Ok, I figured out what is going on here. What is happening is
that doing a 'rename' does not modify the file, so no new history
is being added. A file create modifies the file, of course. A 'rm'
will also modify the file because it drops the hardlink count by 1,
but a 'mv' does not have to modify the file.
The undo program fetches the history internally in order to get the
most recent transaction id, and then tries to open the file using
that transaction id before printing the history.
however, when you've mv'd the file, that transaction id will be prior
to when the mv was made, so undo's attempt to open the file using
the new name will fail.
Pretty cool!
For the moment, so things work somewhat as expected, I will adjust
the undo program to attempt to open the 'current' file under its new
name if it is unable to open the file via the transaction id. That
will help display the history, but the diff feature will probably still
fail.
So undo isn't going to be perfect, it will not be able to access the
file for any period prior to it being renamed unless you also know
the original name (prior to the mv). If you do know that name then you
are golden.
-Matt
Updated by thomas.nikolajsen about 16 years ago
Matt did commit enhanchement to undo program.
Actions