Duy Nguyen <pclo...@gmail.com> writes:
> On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer <t.gumme...@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.
>> + 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
