[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Link with permissions

From: Robin Farine
Subject: Re: [Gnu-arch-users] Link with permissions
Date: Wed, 29 Sep 2004 17:06:46 +0200
User-agent: KMail/1.6.2

On Wednesday 29 September 2004 09.29, address@hidden wrote:

> How far are we of actually providing a generic `file metadata
> machinery'? Owner, permissions, timestamps, colour, flavour...

How far we are I do not know, but I do not think either we should 
put everything in the same bag. I would separate ownership and 
permissions, or access rights, from meta-data such as color or 
flavor mainly because their role is not clear to me :).

What I am trying to say since the beginning of this discussion is 
that versioning access rights need not to be handled by Arch as 
something different from any other text file. Access rights 
associated with _deployed_ files are not necessarily the same as
the access rights associated with files in a project tree or in a 
revision library. The only thing Arch needs to provide is a hook 
triggered by commands that alter a project tree, e.g. get, replay, 

> Of course, for some attributes on some target systems you have
> to perform an actual mapping [on unix: owner <--> chown()
> perms <--> chmod() and so on, as far as your capabilities
> allow it. What to do when not? What to do with `other'
> metadata: e.g. WinNT ACLs on unix?]

It depends on the project. In a lot of projects, we just do not 
care about the access rights. For projects where they are 
important, nothing prevents us from having more than one access 
right description file, each using a syntax adapted to the targeted 

Again, the tool that manages access rights does not have to be 
tightly integrated with Arch, it just depends on the output of 
'inventory'. So support for a new scheme of access rights can be 
added later without incidence on Arch code or archives or project 
trees or revision libraries.

Now, even if people think the current mechanism is what they need 
and that I am just hand waving, fine, then being able to completely 
disable the current mechanism (.arch-params option ?) would be 
perfect so that we can have readonly files in revision libraries 
and get rid of the annoying changes in permissions caused by 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]