From: Nguyen Thai Ngoc Duy Date: Tue, 08 May 2012 14:34:30 GMT Subject: Re: Index format v5 Message-ID: In-Reply-To: Sorry I replied too fast. On Tue, May 8, 2012 at 9:25 PM, Nguyen Thai Ngoc Duy wrote: > On Tue, May 8, 2012 at 9:11 PM, Thomas Gummerer wrote: >>> * "160-bit object name for the object that would result from writing >>>   this span of index as a tree."  Is this always valid? >> >> No, this is only valid if the entry count is not -1. It's clarified >> now. > > ..and.. > >> The entry_count in the index is only valid, if the cache-tree is valid, >> which is not always the case. > > I think your trees are the cache-trees already. For invalid > cache-trees, you can just use all-zero sha-1 as the indicator. Then > entry_count can go away. Furthermore, in directory entry format: The last 24 bytes (4-byte number of entries + 160-bit object name) are for the cache tree. An entry can be in an invalidated state which is represented by having -1 in the entry_count field. If an entry is in invalidated state, the next entry will begin after the number of subtrees, and the 160-bit object name is dropped. Dropping objname out of invalid (cache-)trees is a bad idea. When you generate tree objects (aka cache_tree_update), you'll need objname field again, which means structure change and directory entry rewrite. If objname is always there, you can just overwrite objname with new value. Though this may bring race condition issue back to directory entries. The same approach on file entries might be reused. -- Duy