HAMMER history friendly backup tool

[Tomohiro Kusumi]

I think editors often do something similar if the program generates
some sort of backup file.

You can easily check this with ls -i.
If the inode number has changed, it's likely that the program has
unlinked (removed) or renamed the file and then recreated later.
In the example below, vim does this but vi doesn't.

# ls -li sys/vfs/hammer/hammer.h
24339829639 -rw-r--r--  1 root  wheel  62801 Apr 25 12:12
sys/vfs/hammer/hammer.h
# vim sys/vfs/hammer/hammer.h         /* edit and :wq */
# ls -li sys/vfs/hammer/hammer.h
24339829640 -rw-r--r--  1 root  wheel  62807 Apr 25 12:12
sys/vfs/hammer/hammer.h
# vim sys/vfs/hammer/hammer.h         /* edit and :wq */
# ls -li sys/vfs/hammer/hammer.h
24339829641 -rw-r--r--  1 root  wheel  62813 Apr 25 12:12
sys/vfs/hammer/hammer.h
# vi sys/vfs/hammer/hammer.h         /* edit and :wq */
# ls -li sys/vfs/hammer/hammer.h
24339829641 -rw-r--r--  1 root  wheel  62819 Apr 25 12:18
sys/vfs/hammer/hammer.h
# vi sys/vfs/hammer/hammer.h         /* edit and :wq */
# ls -li sys/vfs/hammer/hammer.h
24339829641 -rw-r--r--  1 root  wheel  62831 Apr 25 12:19
sys/vfs/hammer/hammer.h


It seems rename(2)/open(2) is doing this.
I did below on freebsd since truss on dfly seems to be broken (it
wasn't before).

# truss -o truss.out vim sys/vfs/hammer/hammer.h
# grep "sys/vfs/hammer/hammer.h" truss.out
...
unlink("sys/vfs/hammer/hammer.h~")               ERR#2 'No such file
or directory'
rename("sys/vfs/hammer/hammer.h","sys/vfs/hammer/hammer.h~") = 0 (0x0)
openat(AT_FDCWD,"sys/vfs/hammer/hammer.h",O_WRONLY|O_CREAT|O_TRUNC,0644)
= 3 (0x3)
...


2016-04-25 10:41 GMT+09:00 Predrag Punosevac <punosevac72 at gmail.com>:
> Tomohiro Kusumi <kusumi.tomohiro at gmail.com> wrote:
>
>> An editor like vim (under a certain condition vim uses) can't retain
>> the history as well.
>>
>> If the application creates a new inode with the same path, the history
>> is gone, because hammer looks up btree for history using inode # along
>> with other keys.
>> It's the same path, but different entity.
>>
>
> Is this vim specific or does it also hold true for nvi or nvi2?
>
> Predrag
>
>>
>>
>> 2016-04-25 6:27 GMT+09:00 Bomrek Koganvutram <232.20711 at chiffre.aleturo.com>:
>> > * Predrag Punosevac on Tue, Mar 15, 2016 at 07:02:06PM -0400:
>> >> It looks increasingly unlikely that I will get any suggestions to the
>> >> original question so I am just going to post my own "solution" to the
>> >> original problem.
>> >
>> >> I remember that after Unison sync the file history was lost. What I
>> >> didn't remember until today was that Peeter noticed that the same was
>> >> true with rsync
>> >
>> >> https://marc.info/?l=dragonfly-users&m=135885584004499&w=2
>> >>
>> >> which indeed shares the main algorithm with Unison.  He also noticed
>> >> that using scp or even a cp over NFS (my observation which is fully
>> >> tested) will play well with HAMMER history. So long story short it would
>> >> be fairly easily to cook up such a backup tool which will traverse the
>> >> on my home directory (running OpenBSD) and just cp the files which have
>> >> changed since the last run. I also tested rdiff-backup if anybody cares
>> >> and the result is the same as with rsync and unison.
>> >
>> > Your post is now somewhat dated, but just in case:  Have you tried using
>> > ???--inplace??? with rsync?  My guess is that it???s the way how rsync and
>> > similar tools create their files that breaks HAMMER history:  Instead of
>> > overwriting the file, it is replaced by a new file.  Since it???s a -new-
>> > file, a new history will start there.
>> >
>> > With ???--inplace???, rsync instead overwrites the original file (which has
>> > all kinds of drawbacks, that???s why it isn???t the default), but for your
>> > use case perhaps it???s worth a try.
>> >
>> >> I remember that after Unison sync the file history was lost. What I
>> >> didn't remember until today was that Peeter noticed that the same was
>> >> true with rsync
>> >
>> > I have used Unison a few years back, and it -does- use the same
>> > replace-with-new-file-approach, pretty much for the same reasons.
>> >
>> >> Personally I decided to run HAMMER snapshot as a cron job after rsync
>> >> and in that way preserve the older version of files.
>> >
>> > That would have been my second suggestion; it may not be as convenient
>> > as ???undo???, but at least the data is known to be preserved.
>> >
>> >
>> > Sorry for the late answer; I flagged it a few weeks ago, but then work
>> > got the better of me and I completely forgot. :o)
>> >
>> >
>> > Cheers,
>> >     Bomrek
>> >
>> >
>> > --
>> > Was wir brauchen sind ein paar verr??ckte Leute
>> > -- seht euch an, wohin uns die Normalen gebracht haben.
>> >                 -- George Bernard Shaw