Re: confused about preserved permissions

From: David Kastrup <dak@gnu.org>
Date: Aug 20, 2007, 18:44 UTC
Message-ID: <86r6lygi6f.fsf@lola.quinscape.zz>
In-Reply-To: <20070820181357.GA8264@glandium.org>

Mike Hommey <mh@glandium.org> writes:

Show 10 quoted lines

> On Mon, Aug 20, 2007 at 07:58:43PM +0200, David Kastrup <dak@gnu.org> wrote:
>> > I also never understood why there were no permissions set on
>> > directories in trees...
>> 
>> Because directories are not actually tracked.  They are created and
>> deleted as-needed.
>
> I don't see why it would prevent to have a permission set to
> it... the permission technically can be recorded in the parent tree,
> along its sha1. Filesystems are also like this.

No, they aren't. Filesystems don't create and delete directories on the fly. If we record any information about a directory, deleting it automagically would not be appropriate since we would lose information that has not been explicitly deleted.

Show 13 quoted lines

>> Other permissions would correspond to a tracked directory.  I am still
>> stuck over the representation in the index.
>> 
>> One idea is to unconditionally have an entry "dirname" without
>> permissions, and optionally "dirname/" with permissions iff the
>> directory is supposed to be tracked, both to be sorted in
>> alphabetically.  The idea of the first entry is being able to detect
>> merge conflicts without extra passes.
>> 
>> But I have not worked on the stuff for a while.
>
> I don't see why you would need an additional entry for the directory
> permission.

One doesn't. It would be just there to facilitate single-pass detection of merge conflicts. No non-redundant information content to it at all, but it delivers the "we'll need a directory here" information earlier in the sort order.

But one can probably do without that by just stashing away non-directory entries namex* possibly colliding with a tree until the opportunity for namex/* has passed by, and then processing them. That makes for a cleaner index format.

There is still the question when one stores just a single entry whether to sort this under "namex" or "namex/" and whether to also have it appear when it corresponds to a non-tracked directory.

It does not really make sense settling on one format before one implements the various merge/update/checkout utilities since then one sees what is most convenient.

Show 9 quoted lines

>> > nor why, while the sha1 for child objects are "packed", the modes
>> > aren't...
>> 
>> Because a change of the mode of a file will then not cause different
>> sha1 sums at the file level.
>
> I think i wasn't clear enough... I just wondered why the format for tree
> entries is something like (if you'd write it in perl):
> sprintf "%06o %s\0%s", $mode, $file, pack("H[40]", $sha1)

Now I am sure I don't get your point.

-- 
David Kastrup