Re: Storing permissions

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 17, 2005, 04:48 UTC
Message-ID: <Pine.LNX.4.58.0504162138020.7211@ppc970.osdl.org>
In-Reply-To: <20050416183023.0b27b3a4.pj@sgi.com>

On Sat, 16 Apr 2005, Paul Jackson wrote:

Show 12 quoted lines

>
> Morten wrote:
> > It makes some sense in principle, but without storing what they mean
> > (i.e., group==?) it certainly makes no sense. 
> 
> There's no "they" there.
> 
> I think Martin's proposal, to which I agreed, was to store a _single_
> bit.  If any of the execute permissions of the incoming file are set,
> then the bit is stored ON, else it is stored OFF.  On 'checkout', if the
> bit is ON, then the file permission is set mode 0777 (modulo umask),
> else it is set mode 0666 (modulo umask).

I think I agree.

Anybody willing to send me a patch? One issue is that if done the obvious
way it's an incompatible change, and old tree objects won't be valid any
more. It might be ok to just change the "compare cache" check to only care
about a few bits, though: S_IXUSR and S_IFDIR. And then always write new 
"tree" objects out with mode set to one of
 - 040000: we already do this for directories
 - 100644: normal files without S_IXUSR set
 - 100755: normal files _with_ S_IXUSR set

Then, at compare time, we only look at S_IXUSR matching for files (we never compare directory modes anyway). And at file create time, we create them with 0666 and 0777 respectively, and let the users umask sort it out (and if the user has 0100 set in his umask, he can damn well blame himself).

This would pretty much match the existing kernel tree, for example. We'd end up with some new trees there (and in git), but not a lot of incompatibility. And old trees would still work fine, they'd just get written out differently.

Anybody want to send a patch to do this?

		Linus