RE: [Gnu-arch-users] Re: patch: clean up some cacherev mess

[Derek Zhou]

See below: 

> -----Original Message-----
> From: Mikhael Goikhman [mailto:address@hidden 
> Sent: Sunday, November 20, 2005 4:14 AM
> To: Derek Zhou
> Cc: address@hidden
> Subject: Re: [Gnu-arch-users] Re: patch: clean up some cacherev mess
> 
> On 19 Nov 2005 16:40:26 -0800, Derek Zhou wrote:
> > 
> > I am a little bit confused here. 
> 
> It is a bit hard to keep a long discussion if one top-posts.
Sorry about that. I am stuck with this stupid outlook here.
> 
> > Neither my home dir nor /tmp are g+s?
> 
> My point was for project directories configured for multiple 
> developers.
Isn't that against the very spirit of revision control? Do you actually
have multiple people writing to the same tree?
> 
> > An what do you mean by non-transient tmp_dir?
> 
> I mean, the directory that is left after tla is finished.  tla creates
> many such sub-directories in the project tree, library or archive.
> All of them should have mode 2775 (664) recursivelly if the parent
> directory has such mode and umask 2 is used. Otherwise, it is a bug.
> 
> Transient directories (shortly removed) are less important, 
> except when
> they are used to create tar.gz. I wanted to raise the awareness and to
> check consequences in each individual case rather than 
> blindly switching
> to /tmp. Thank you.
Did you actually see permission messed up because of this patch?
xterm:~$ mkdir a
xterm:~$ chmod 2775 a
xterm:~$ cd a
xterm:~/a$ mkdir b
xterm:~/a$ ls -al
total 12
drwxrwsr-x    3 dzhou    dzhou     4096 Nov 20 11:35 .
drwxr-xr-x   39 dzhou    dzhou     4096 Nov 20 11:35 ..
drwxr-sr-x    2 dzhou    dzhou     4096 Nov 20 11:35 b
It looks like s bit will only enforce gid, but not group permission,
which is determined by umask.
tar can not preserve pid/gid, but only permissions. 
In addition to that, cacherev will get a revision first, which has all
the permission set as in your archive. So no matter what permission bits
should not get changed. 
Anyway, cacherev does not has to be invoked from a checked out tree, and
it just blindly wrote to ".", which may not even be writable. That was a
serious bug. 
> 
> Regards,
> Mikhael.
> 
Derek