Date: Wed, 22 Oct 2008 19:57:55 +0200 From: Polytropon <freebsd@edvax.de> To: perryh@pluto.rain.com Cc: freebsd-questions@freebsd.org Subject: Re: Inode numbering Message-ID: <20081022195755.aaf4a1a0.freebsd@edvax.de> In-Reply-To: <48fbea58.MJTNxk/Em/TmZNW9%perryh@pluto.rain.com> References: <20081019044058.9ff31b6f.freebsd@edvax.de> <48fac99c.v09a2DdmpE7xdWZS%perryh@pluto.rain.com> <20081019185224.d0ce3bd3.freebsd@edvax.de> <48fbea58.MJTNxk/Em/TmZNW9%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 19 Oct 2008 19:18:00 -0700, perryh@pluto.rain.com wrote: > You may be able to reuse some code from dump(8). Hey, that's a good idea! After having had a short look at the source of dump, I developed another idea: dump applies some criteria weather to access (and dump) an inode or not. Maybe it's possible to change these criteria within dump, recompile it and then use it to dump any (!) existing inode. The only problem would be to implement a workaround for those that don't have a parent inode anymore (file name lost), i. e. those on the 1st hierarchy stage within the home directory. > 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. I have to admit that it's a bit complicated. Programming applications in C is my forte, hehe, but dump's C code is very much lowlevel. I'm so lucky FreeBSD has the right attitude towards documentation. So I will find a way to implement it, I hope. -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081022195755.aaf4a1a0.freebsd>