Re: [Gnu-arch-users] {arch} perms -> shared revlib?

[John Meinel]

Zenaan Harkness wrote:
[...]
> That is excellent information! Thank you very much!
>
> I have a little question, after having done the above (rm temporaries +
> blow away old revlib, and "tla get $archat" to repopulate the revlib):
>
> ___ 04-09-24 09:43:00 address@hidden:~ $ lal \
> revlib/address@hidden/cpc/cpc--stable/cpc--stable--1.0/cpc--stable--1.0--patch-5/\{arch\}/
> total 24
> -rw-rw-r--    1 arch     arch           50 Sep 24 09:42
> ++default-version
> drwxr-xr-x    2 arch     arch         4096 Sep 24 09:42 ,,inode-sigs/
> -rw-rw-r--    1 arch     arch           52 Sep 24 09:42
> .arch-project-tree
> -rwxrwxr-x    1 arch     arch         6809 Sep 24 09:42 =tagging-method*
> drwxrwxr-x    5 arch     arch         4096 Sep 24 09:42 cpc/
>
>
> and as you will note, ,,inode-sids _in the revlib_,
> is not group writable. It's the only file like this in the revlib.
>
> Is this a problem for my shared revlib?
>
> If so, can it be fixed?
>
> thanks again
> zenaan

Well, from my knowledge this shouldn't be a problem. ,,inode-sigs is not 
supposed to ever change. It is basically like a hash checksum of the 
files in the revlib to make sure they haven't changed. (it is actually 
some group of timestamp, inode number, file size, ....)

I'm pretty sure if it is created in that location, it isn't meant to 
change, so you shouldn't need write access. You might run into problems 
if someone needs to clean up the revlib, and doesn't have access.

Of course, the *proof* is to run 2 clients under different users and see 
if you have problems :)

let us know what you find.


[off-topic about inode-sigs]

I know *why* arch keeps a pretty stringent check on it's 
pristines/revlib. A corrupt pristine/revlib would generate bogus 
changesets, etc.

But I know we've had problem with the specific incantation of ,,inode-sigs.

I was just wondering if we could do a 2-tiered approach. Have some sort 
of inode-sig that might change without corruption, but is very fast to 
evaluate. This should also *always* find a change no false negatives. 
(Such as ctime (or maybe mtime)). Then also include a md5hash. So if the 
first *fast* one says the file changed, you could check the second one 
to verify, and then if it didn't change, you just update the inode-sig 
to the newly correct value.

We didn't use md5sums because hashing the whole tree is slow. But if we 
just hash things that seem to have changed, wouldn't that be fast?

Also, if the current inode-sig only uses information from a single stat, 
I don't think we can out-perform it time wise. So there may be no 
benefit. Just something I was thinking about.

John
=:->

signature.asc
Description: OpenPGP digital signature