Hello Bert,
On Sunday 07 September 2008 Bert Huijben wrote:
> > > Why is the unix specific numeric ID required and the more generic
> > > username optional?
> > If you're restoring 5 files with different owners, but your /etc/passwd
> > doesn't list them (think desaster recovers - you're trying to get
> > /etc/passwd back out of your repository :-), you should at least
> > get the 5 different UIDs back.
> > (Same behaviour with tar and rsync.)
>
> I know the problem on unix systems. (My @home server(notebook) runs
> FreeBSD). But as a generic property I look at how I would implement this
> feature for any non-unix OS. In that case making the username optional is a
> very strange decision.
No, it isn't. It's entirely possible to have a file with some userID that has
no name mapped ... which string would you pass into the property?
> To keep things generic I could think of making the username required and
> document the unix-specific behavior on uids. (Or maybe use a owner and a
> unix-uid property)
>
> Currently, if I would implement this property on Windows,
Windows couldn'd cope with that anyway, since an ACL can't be stored as a
(owner, group, mode) tuple.
> I would have to
> make up some kind of uid and then provide a username. (I can't convert a
> 'S-1-423-64-53-42367' like SID in a valid 32 bit uid)
No, but I'd think that just the last 32bit (omitting the machine/domain
prefix) should work; restoring on any other machine would look up the
username (which could be domain\user!), and could fall back to using <local
sid>-<userid>.
Using some other machine sid doesn't make much sense anyway.
> Guessing uid 0, wouldn't be very polite to most unix implementations and
> any positive number < MAX_INT might cause other problems. What would a
> valid guess id for this case be? Is "-1" numeric enough for this situation
> or should I just start with whitespace?
I think that's no problem, see above.
> I think there is a current implementation of these properties, so changing
> the definition might be no longer possible.
Yes, correct.
> But I would like to see an
> answer on these questions in the documentation when we declare the
> properties as standard and/or plan to implement the feature in subversion
> itself.
Is that enough of an explanation? Or do you see some other aspects that need
more text?
> > I'm a bit afraid of just using the svn_props.h file from trunk, because
> > that could create unnecessary conflicts on a merge later; but OTOH, the
> > meta-data branches are too old for automatic merging anyway. There'd be
> > a lot to do manually - more or less a rewrite, I think.
> Looking at the branch history I think using merge tracking from trunk is
> pretty save. (I don't see any merges from trunk into the branch and the
> implicit merge history is valid).
If that's good enough, fine.
> > Thank you; I tried, but got "Authentication failed".
> > Either user "pmarek" is revoked for the subversion repository
> > completely,
> > or at least limited to the meta-data branch.
> >
> > I'm attaching the new patch.
> I don't think you are limited in where you can commit, so I guess you have
> a problem with your credentials.
Well, they still work fine on fsvs.tigris.org - but not on svn.collab.net
(which they did for the meta-data branch!), so I'm a bit lost.
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-07 17:18:33 CEST