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

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

Re: [Gnu-arch-users] BUG: feature request: 'tla chmod' which 'touch'es f


From: Matthew Dempsky
Subject: Re: [Gnu-arch-users] BUG: feature request: 'tla chmod' which 'touch'es files
Date: Sun, 26 Sep 2004 16:44:54 -0500
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Harald Meland <address@hidden> writes:

> [Matthew Dempsky]
>
>>> From my understanding, the only "important" permission to keep track
>>> of is the "executable" bit. So that when I write a script, it will
>>> stay executable between checkin/checkout.
>>
>> Yeah, that seems important to me too.
>
> I'm not sure if you're talking "permission bits to store in inode
> sigs" or "permission bits that are versioned by Arch" here.

Well, both really.  If we're going to correctly determine when the
revlibs have been corrupted then we need to keep permission data in
the inode sigs file.

> If it's the latter, a reduction of the current tla feature set to
> include only a single "executable file" boolean (the way I think CVS
> does this) would make Arch less suitable for e.g. keeping track of my
> home-directory dotfiles; some of which I'd like to be world readable,
> while other should only be readable by me.

It would make arch on its own less immediately suitable to this, yes.
However, I'm not outruling the possibility of some higher-level
functionality that can correctly determine how to set permissions for
files in the tree.  If we're going to deal with permissions ourselves,
we need to fix how it's done to handle both your scenario (single
user, $HOME config) and the scenario I pointed out (multi-site with
different umasks).

One thing to note about this presently, however, arch doesn't know
what group to create a file in.  If you have dotfiles in your home
directory with ownership foo:bar and rw-rw-r--, if you recreate $HOME
it will have ownership foo:foo so if that matters to you at all, you
already need some extra functionality layered on arch.

> The main reason I'd be sceptical to adding owner (and group) support,
> is that it seems hard to find a generic answer to "When, if ever,
> should patch application report mismatching owners as a conflict?"

Well, I'm not one to rule out managing ownership just yet, but I think
we need to carefully consider how to do it.  Maybe we could add some
{arch} configuration file that specifies whether we want to keep exact
permissions/ownership info, or we want to only track executable flags.




reply via email to

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