From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 16 17:37:49 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3E7916A403; Mon, 16 Jul 2007 17:37:48 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [81.187.76.162]) by mx1.freebsd.org (Postfix) with ESMTP id 530D413C4B4; Mon, 16 Jul 2007 17:37:48 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost.infracaninophile.co.uk [IPv6:::1]) by smtp.infracaninophile.co.uk (8.14.1/8.14.1) with ESMTP id l6GHbV5V066239; Mon, 16 Jul 2007 18:37:33 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Authentication-Results: smtp.infracaninophile.co.uk from=m.seaman@infracaninophile.co.uk; sender-id=permerror; spf=permerror X-SenderID: Sendmail Sender-ID Filter v0.2.14 smtp.infracaninophile.co.uk l6GHbV5V066239 Message-ID: <469BACDB.1040608@infracaninophile.co.uk> Date: Mon, 16 Jul 2007 18:37:31 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.4 (X11/20070619) MIME-Version: 1.0 To: Tim Kientzle 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> In-Reply-To: <469B8C40.9020603@freebsd.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtp.infracaninophile.co.uk [IPv6:::1]); Mon, 16 Jul 2007 18:37:43 +0100 (BST) X-Virus-Scanned: ClamAV 0.91/3681/Mon Jul 16 14:16:18 2007 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_POLICY_SIGNSOME, DKIM_POLICY_TESTING,NO_RELAYS autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-hackers@freebsd.org Subject: Re: Tar output mode for installworld X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 17:37:49 -0000 -----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-----