Re: tracking perms/ownership

From: Josh England <jjengla@sandia.gov>
Date: Aug 24, 2007, 07:22 UTC
Message-ID: <1187940171.6357.59.camel@beauty>
In-Reply-To: <7vtzqpsy3q.fsf@gitster.siamese.dyndns.org>

On Thu, 2007-08-23 at 15:08 -0700, Junio C Hamano wrote:

Show 13 quoted lines

> "Josh England" <jjengla@sandia.gov> writes:
> 
> > Looking at the index struct, it already has fields in it for file mode
> > uid and gid (woohoo!).
> 
> I can see that storing textual names in gitattributes and having
> the root user run git so that it can chown(), would work.
> 
> But this is only about checkout.  After you chown a file in the
> work tree and run update-index, next write-tree would not record
> it, as there is no place in tree objects to record uid/gid.
> You would need to arrange so that a matching change is made in
> the gitattributes file if you go that route.

That's ok. Any place to store the data is fine by me. I'm just concerned about some comments I saw in attrs.c <line13>: /* The basic design decision here is that we are not going to have insanely large number of attributes. This is a randomly chosen prime. */ #define HASHSIZE 257

Using a brute force perm/ownership attribute set for every file, assuming a modestly populated linux distribution image having upwards of 150,000 files/directories in it, thats sticking over 100,000 attributes into some .gitattributes file somewhere. Do you think the gitattributes system can handle this kind of abuse?

Show 11 quoted lines

> If you had:
> 
> 	etc/*		owner=root
>         etc/frotz	owner=nobody
> 
> in gitattributes, and you did a checkout.  You chown etc/nitfol
> with "chown printer etc/nitfol".  Somebody needs to add a line
> 
> 	etc/nitfol	owner=printer
> 
> to gitattributes before you make the commit.

Unless this 'somebody' is an automated process that will never fly. I want git to do it for me when the right config/attr is set (maybe at update_index time). Thats where my concern about the gitattributes system comes from. What's going to happen when I stick 150,000 (est) attributes in there?

Show 6 quoted lines

> Maybe the chown
> was not about etc/nitfol but about making etc/frotz owned by
> root.  Then you would, instead of adding the etc/nitfol line,
> remove existing etc/frotz line so that earlier glob would
> capture and express the idea of making everything owned by
> root.  I suspect this would get rather tricky quickly.

Maybe doable though. Starting from the root of the tree, traverse downwards and only add new attributes when a file or dir's ownership has changed from the parent, maybe. This could optimize away many of the attributes needed. I think a good place might be right in index_path() because the lstat data is fresh and accessible. Writing attrs out to file if necessary should hopefully not add too much overhead.

-JE