From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Timothy A. Seufert" Subject: Re: HFS+ support (read-only) Date: Fri, 7 Jun 2002 12:16:31 -0700 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: References: <20020606052443.A21838@pants.nu> <20020606132356.B9152@plato.local.lan> <20020606232543.C9152@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Return-path: In-Reply-To: <20020606232543.C9152@plato.local.lan> To: Ethan Benson , linuxppc-dev@lists.linuxppc.org, linux-fsdevel@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org At 11:25 PM -0800 6/6/02, Ethan Benson wrote: >On Thu, Jun 06, 2002 at 03:50:31PM -0700, Timothy A. Seufert wrote: >> The OS needs >> a database of all files that are hardlinked, with full reverse >> mappings, so that whenever a file with hardlinks is unlinked it has >> enough information to replace one of the hardlinks with the real file. > >i don't know about that, maybe. to be honest it would not surprise me >if apple just let that break. Oh, come on. :) I just tested it, they didn't let it break. >> (For efficiency I'd want a flag bit in the metadata of each file to >> indicate that it has been hardlinked, to avoid searching the table >> when deleting files that have no hardlinks. For even more >> efficiency, a direct pointer to the table entry.) > >you cannot use the word efficient to describe this puke inducing >kludge. the efficient way is to design the filesystem properly to >begin with, which apple did not do with HFS+. The kludge part is trying to retrofit features like hardlinks into a FS which wasn't designed to naturally support them (as classic UNIX inode FS designs do). Aside from that I see nothing wrong with the basic design of HFS+. -- Tim Seufert