On Wed, May 25, 2011 at 10:35 AM, Stephan Beal <sgb...@googlemail.com>wrote:
> On Wed, May 25, 2011 at 5:10 PM, Joan Picanyol i Puig < > lists-fos...@biaix.org> wrote: > >> Bummer, I incorrectly assumed that fossil tracked all permissions. >> > > System-level config files often need to belong to a specific user and/or > group. So fossil would also have to track user names, and there is no > guaranty that user 'stephan' on host1 is actually the same user as 'stephan' > on host2 (though they tend to be the same person on my systems ;). > Philosophically, i don't think that problem can be solved generically. > Backup systems have to deal with these things. AFAIK, they usually store users and groups by ID, not by name. Even if fossil did support storing/restoring the whole permissions (with > user/group names/IDs), it literally couldn't work for anyone but the root > user: Unix systems won't let a user's process chown a file to a different > user. > Etckeeper does what Joan wants, using Git, Bzr, DARCS, or Mercurial: http://kitenet.net/~joey/code/etckeeper/ Of course you run this as root as you would with any other backup tool. Can't restore a backup, in general, unless you're root. [stephan@cheyenne:~/Documents/Consol/allez/www]$ chown root index.php > chown: changing ownership of `index.php': Operation not permitted > > and one can only chgrp with groups he's a member of: > > [stephan@cheyenne:~/Documents/Consol/allez/www]$ chgrp daemon index.php > chgrp: changing group of `index.php': Operation not permitted > > And what to do on files imported into fossil from Windows and checked out > on Unix systems? > > == Huge Can of Worms > A lot of people seem to be able to use etckeeper just fine. Bill
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
