Date: Thu, 24 May 2001 08:24:29 -0400 (EDT) From: "Andresen,Jason R." <jandrese@mitre.org> To: void <float@firedrake.org> Cc: <hackers@FreeBSD.ORG> Subject: Re: technical comparison Message-ID: <20010524082013.G88992-100000@nausicaa.mitre.org> In-Reply-To: <20010524003731.B25053@firedrake.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 May 2001, void wrote: > On Wed, May 23, 2001 at 09:20:51AM -0400, Andresen,Jason R. wrote: > > > > Why is knowing the file names cheating? It is almost certain > > that the application will know the names of it's own files > > (and won't be grepping the entire directory every time it > > needs to find a file). > > With 60,000 files, that would have the application duplicating > 60,000 pieces of information that are stored by the operating system. > Operations like open() and unlink() still have to search the directory > to get the inode, so there isn't much incentive for an application to > do that, I think. This still doesn't make sense to me. It's not like the program is going to want to do a "find" on the directory every time it has some data it wants to put somewhere. I think for the majority of the cases (I'm sure there are exceptions) an application program that wants to interact with files will know what filename it wants ahead of time. This doesn't necessarily mean storing 60,000 filenames either, it could be something like: I have files fooX where X is a number from 00000 to 60000 in that directory. I need to find a piece of information, so I run that information through a hash of some sort and determine that the file I want is number 23429, so I open that file. I don't expect programs to try to offload this sort of information on the filesystem. Do you have an example of a program that interacts with the filesystem without knowing the names of the files it wants? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010524082013.G88992-100000>