[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: I believe I have found a bug with 'svn mv' + ACL-protected files.

From: Mark Slade <markandrewslade_at_gmail.com>
Date: Fri, 7 May 2010 10:13:55 -0400

All,

Apologies for the delayed response. Yes, my report was not about how the
files were created when deployed, but rather how they were created within a
working copy when an 'svn mv' was done. I probably wouldn't have considered
that it might be a bug if it weren't for the inconsistency: if you perform
those same steps against a *directory*, it retains the ACL as it would if
you had done a 'mv'.

Anyhow, I'm afraid I don't have the working environment to test this against
current, but if you would still like a bug report I would be happy to submit
one.

Mark

On Tue, May 4, 2010 at 3:46 AM, Stephen Butler <sbutler_at_elego.de> wrote:

>
> On May 4, 2010, at 8:39 , Karl Fogel wrote:
>
> > Mark Slade <markandrewslade_at_gmail.com> writes:
> >> Per your Issue Tracker Guidelines, I am seeking somebody who agrees
> >> that this is a bug before I submit it.
> >>
> >> Overview: For files, 'svn mv' does not properly inherit ACL
> >> permissions from the parent directory.
> >>
> >> Steps to reproduce (from a subversion working directory):
> >> 1. setfacl -d -m user:$USER:r-x .
> >> 2. touch foobar
> >> 3. svn add foobar
> >> 4. svn commit -m 'test' foobar
> >> 5. svn mv foobar barfoo
> >> 6. getfacl barfoo
> >>
> >> If you check the ACL for barfoo after steps 2, 3, and 4, you will see
> >> that it has properly inherited the user:jdoe:r-x permission. After
> >> step 5, you will see that barfoo has not. You can circumvent this
> >> behavior by using "mv" instead of "svn mv" in step 5. In this case,
> >> you need to "svn delete foobar" and "svn add barfoo" before you can
> >> commit the move.
> >>
> >> Details:
> >> CentOS release 5.4 (Final), svn 1.4.2 (from yum)
> >>
> >> I'm not sure what else is relevant, so fire away if you have questions.
> >
> > So just to clarify:
> >
> > The expectation is *not* that Subversion would version these ACLS, but
> > rather that, on the client side, an 'svn mv foo bar' would preserve
> > foo's ACLS so that bar has the same ACLs (locally).
> >
> > IOW, you would not expect that when the 'svn mv' is committed and
> > someone *else* checks out a working copy with the new bar in it, that
> > bar to have the ACLs, right?
> >
> > (Btw, I think it's better to just use "foo" and "bar" -- it's a bit hard
> > to keep track of "foobar" vs "barfoo", mentally :-) .)
> >
> > Stephen Butler, I saw your later followup, but were you clear on how
> > limited Mark's proposal actually is?
> >
> > -Karl
>
>
> Ooops, I see I misunderstood the proposal. Thanks, Karl.
>
> So, Mark, go ahead and open the issue. It'd be nice to reproduce it
> using the latest Subversion release (1.6.11).
>
> Cheers,
> Steve
>
> --
> Stephen Butler | Software Developer
> elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
> fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
> fax: +49 30 2345 8695 | http://www.elegosoft.com
> Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
>
>
Received on 2010-05-07 16:14:33 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.