From owner-freebsd-questions@FreeBSD.ORG Wed Oct 22 17:57:59 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58C7D1065679 for ; Wed, 22 Oct 2008 17:57:59 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id 185D58FC0C for ; Wed, 22 Oct 2008 17:57:58 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r55.edvax.de (port-92-195-41-11.dynamic.qsc.de [92.195.41.11]) by mx01.qsc.de (Postfix) with ESMTP id 44CC051459; Wed, 22 Oct 2008 19:57:56 +0200 (CEST) Received: from r55.edvax.de (localhost [127.0.0.1]) by r55.edvax.de (8.14.2/8.14.2) with SMTP id m9MHvtvM003679; Wed, 22 Oct 2008 19:57:55 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Wed, 22 Oct 2008 19:57:55 +0200 From: Polytropon To: perryh@pluto.rain.com 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> Organization: EDVAX X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: Inode numbering X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2008 17:57:59 -0000 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, ...