Hi,
On Tue, 31 Oct 2006, Junio C Hamano wrote:
> So the next thing to see is why adjust_shared_perm() is failing
> for you.
>
> Oops.
>
> I think this function is broken at the concept level. This is
> to work around people's broken umask (when you are working with
> other people, your umask should not be stronger than 007) and
> tries to flip group writability bit on.
>
> First of all, if the necessary bits are already on, it is not
> necessary to run chmod(),
right
> but more importantly, if the directory in question was created by
> somebody else, I do not think this chmod() would succeed even if you are
> in the same group as the owner (i.e. previous creator) of the directory.
But if somebody else created it, it should already have the correct
permissions in the first place (unless the user played around with them,
which is not a pilot error, but a willfull pointing of the barrel in the
general direction of your knee).
> [jc: I am CC'ing Johannes to blame him on commit 457f06d6;
> git-pickaxe is turning out to be quite handy ;-)
I am hating the tool already.
> if (dir) {
> *dir = 0;
> mkdir(filename, 0777);
> - if (adjust_shared_perm(filename))
> + if (adjust_shared_perm(filename)) {
> + *dir = '/';
> return -2;
> + }
How about this instead:
- mkdir(filename, 0777);
- if (adjust_shared_perm(filename))
+ if (!mkdir(filename, 0777) && adjust_shared_perm(filename)) {
+ *dir = '/';
return -2;
+ }
Ciao,
Dscho
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html