Re: [PATCH v2 10/19] documentation: add documentation of the index-v5 file format

From: Thomas Gummerer <t.gummerer@gmail.com>
Date: Jul 17, 2013, 08:09 UTC
Message-ID: <87txjtsj4a.fsf@gmail.com>
In-Reply-To: <CACsJy8Ckcuk11Vmhyo-2wk6bMtNo17=Q9KXU9B-JAi0j7Cmi+A@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 9 quoted lines

> On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
>> +== Directory offsets (diroffsets)
>> +
>> +  diroffset (32-bits): offset to the directory relative to the beginning
>> +    of the index file. There are ndir + 1 offsets in the diroffset table,
>> +    the last is pointing to the end of the last direntry. With this last
>> +    entry, we are able to replace the strlen of when reading the directory
>
> strlen of what?

Of the dirname.  Will fix in the re-roll, thanks for noticing.

Show 14 quoted lines

>> +    name, by calculating it from diroffset[n+1]-diroffset[n]-61.  61 is the
>> +    size of the directory data, which follows each each directory + the
>> +    crc sum + the NUL byte.
>> +
>> +  This part is needed for making the directory entries bisectable and
>> +    thus allowing a binary search.
>
> Just thinking out loud. Maybe this section and fileoffsets should be
> made optional extensions. So far I see no use for them. It's nice for
> a program to occasionally look at a single entry, but such programs do
> not exist (yet). For inotify monitor that may want to update a single
> file's stat, it could regenerate the index with {dir,file}offsets
> extensions the first time it attempts to update the index, then it
> could do bsearch.

There is a use already, namely saving the strlen for the filename. Previously we had the length of the filename in the lower bits of the flags, but decided to remove it to avoid having extended flags. That in addition to the use case in the future warrants keeping them in the index, I think.