Date: Sun, 19 Oct 2008 19:18:00 -0700 From: perryh@pluto.rain.com To: freebsd@edvax.de Cc: freebsd-questions@freebsd.org Subject: Re: Inode numbering Message-ID: <48fbea58.MJTNxk/Em/TmZNW9%perryh@pluto.rain.com> In-Reply-To: <20081019185224.d0ce3bd3.freebsd@edvax.de> References: <20081019044058.9ff31b6f.freebsd@edvax.de> <48fac99c.v09a2DdmpE7xdWZS%perryh@pluto.rain.com> <20081019185224.d0ce3bd3.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Polytropon <edvax.de!freebsd@agora.rdrop.com> wrote: > ... It will force me to > do what I originally intended to do: Iterate from 2 up > to the maximal number and then check the availability, > and, if given, "trace back" the ".. chain" to an existing > directory entry point - or re-create one, if it is missing, > too. Will be a lot of work, but I think I can learn much > from this. You may be able to reuse some code from dump(8). When doing an incremental dump, it reads through the inodes, makes a list of those which are newer than the previous dump, then recursively locates all parent directories of selected inodes and adds them to the list. (When doing a level 0 dump, it does the same thing but by definition every inode is selected.) Having done all that, it dumps all the selected directories followed by the rest of the selected inodes. Dump's purpose is to ensure that the dump will be complete in the sense of containing the full path to any file that is on the tape, and your purpose is different, but I suspect much of the "find parent" logic may be reusable.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48fbea58.MJTNxk/Em/TmZNW9%perryh>