Date: Mon, 16 Jul 2007 18:37:31 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Tim Kientzle <kientzle@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Tar output mode for installworld Message-ID: <469BACDB.1040608@infracaninophile.co.uk> In-Reply-To: <469B8C40.9020603@freebsd.org> References: <46992FFF.7010906@kientzle.com> <20070714223853.GF16579@britannica.bec.de> <469992CA.6000104@freebsd.org> <4699BE75.2090808@freebsd.org> <20070715133016.GA53853@psconsult.nl> <469A6B73.1030004@freebsd.org> <469B23FE.8060608@infracaninophile.co.uk> <469B8C40.9020603@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Tim Kientzle wrote:
>> Being able to record a series of incremental changes in a filesystem
>> hierarchy, and then roll them back as required. That would be
>> exceedingly useful, and I think your 'ntree' format has virtually
>> everything necessary to do that. The most obvious missing bit I can
>> see is creating a backup of a file before overwriting it with
>> different content.
>
> Is this something that requires changes to the specification
> file format, or just a feature of the tool that uses the
> specification file?
>
> If the former, what do you envision would be required?
In your example earlier you said not entirely unlike the following:
#%ntree
bin/echo contents=my/bin/echo uid=0 gid=0 group=wheel
I've taken the liberty of reordering it a bit, because then it can
be interpreted (for example) as directly translating into a sequence
of shell commands:
cp my/bin/echo /bin/echo
chown 0 /bin/echo
chgrp 0 /bin/echo
chgrp wheel /bin/echo
This could be seen as a fragment of the process of building the /bin
filesystem from scratch, or as a patch to an existing /bin
filesystem, overlaying the echo command with a new version.
Thinking of it as the latter, so long as you know where to copy the
original /bin/echo to and how to record various other metadata then
you can fairly readily write another ntree program that reverses the
effect of this one[*]. The tool used to unpack the ntree file would
have to record the original file metadata (presumably directly in
ntree format), and you'ld probably need a reasonably cunning
approach to storing the backup copies of files so you avoid
accidentally overwriting them. (Use the checksum of the file as the
name to store it under? Some sort of directory hashing probably
useful too)
Cheers,
Matthew
[*] almost literally by reversing the sense of each command and then
reversing the order they are applied. Admittedly this is a trivial
example, but I don't see why that approach shouldn't work in general.
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGm6zb8Mjk52CukIwRCCTtAJ9cLxb13VEmr06WVKX4r7D3z9UkVQCePB94
SE++fRzlgNecWtv6svCYIzE=
=o4XJ
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?469BACDB.1040608>