gnu-arch-users
[Top][All Lists]
Advanced

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

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


From: tomas
Subject: Re: [Gnu-arch-users] Link with permissions
Date: Thu, 30 Sep 2004 09:37:44 +0200
User-agent: Mutt/1.5.3i

On Wed, Sep 29, 2004 at 05:06:46PM +0200, Robin Farine wrote:
> 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 :).

Nor are NT's ACLs clear to me either :-)

What I want to say is that the importance of some specific meta-data
are in the eye of the beholder. This is what lead me to think of
this generic thing in the first place. Others may care about colour,
whatever that may be. We unixers just ignore that.

> 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.

Seems we agree, then.

>                                               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.

Good point.

>                   The only thing Arch needs to provide is a hook 
> triggered by commands that alter a project tree, e.g. get, replay, 
> update,.

Yes, and each platform will pick the attributes it cares about
and do whatever is necessary. A convention about how each platform
interprets the attributes might help, but won't be necessarily part
of Arch. Right?

[...]

> 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 
> scheme.


Ah, I see. You propose even a more generic scheme: a mechanism to
provide a mechanism to deliver extended attributes. I think I
understand now.

> 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 
> Windows/samba.

Now I think I like your approach. Maybe something is missing, though:
a set of `good practices' to guide people on how to use that. Just
to keep different uses from stomping onto each others.

Regards

-- tomás

Attachment: pgpWVkqhzuMbQ.pgp
Description: PGP signature


reply via email to

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