From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5d375e920809241131v46962f15j5e9b4c7837238c29@mail.gmail.com> Date: Wed, 24 Sep 2008 20:31:00 +0200 From: Uriel To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <14ec7b180809240715s5b0ad85ej1d4bce241d450a5b@mail.gmail.com> Subject: Re: [9fans] ape/psh can't exec in 9vx Topicbox-Message-UUID: 14086600-ead4-11e9-9d60-3106f5b1d025 Or we could use extended attributes to store the plan9-related bits. I'm joking, I'm joking! I just couldn't resist mentioning such wicked idea ;)) Probably having fossil become part of the default setup would be the best. Peace uriel On Wed, Sep 24, 2008 at 5:56 PM, Steve Simon wrote: > I may be wrong but I assumed the problem with replica was that unless you run 9vx > setuid to root and trust the permssion checking in the host interface there is > no way for wstat to change the username of a file to anything else that the user > who started 9vx. > > aditionally there may b e no relevant host user to become the owner of the file, > e.g. bootes or glenda. > > If it is just limitations of the host filesystem emulating a 9p server then replica > should work fine when it uses a seperate fossil disk partition rather than a host > filesystem. > > If I am right you could always add a file which contains extra metadata not stored > in the host filesystem (e.g. the append bit, the 't' bit (don't venti) and of > course owner and group - overriding the owner and group from the native filesystem. > > wether this is worth the effort... thats another question. > > alternatively the 9vx host filesystem interface or replica itself could be hacked to > be less strict when wstats()ing. > > then again I may have the wrong end of the stick completely. > > -Steve