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

Re: [Possible Bug] Can't checkout without file/directory ownership

From: Kevin Locke <kevin_at_kevinlocke.name>
Date: Tue, 23 Aug 2011 10:00:05 -0600

Hi Stefan,

Thanks for looking into this, I appreciate it.

On Tue, 2011-08-23 at 11:02 +0200, Stefan Sperling wrote:
> On Mon, Aug 22, 2011 at 04:57:37PM -0600, Kevin Locke wrote:
>> [...]
>> = The Problem =
>> I am unable to work with (checkout/update) a working copy on an NTFS
>> filesystem mounted using NTFS-3G unless it is mounted with uid=me,
>> even when full read/write permissions (fmask=111,dmask=000) are
>> granted. The results are as follows:
>> $ svn co http://svn.apache.org/repos/asf/subversion/trunk testdir
>> svn: E000001: Can't set permissions on '<path>/testdir/.svn/tmp/svn-HZAmRw': Operation not permitted
>> I first encountered this behavior with the version in Debian testing
>> (1.6.17dfsg-1) and I have just confirmed the same behavior is present
>> in trunk.
>> [...]
> [...]
> It is safe to ignore the error you are getting, for two reasons:
> - Subversion is trying to expand the set of permissions, not shrink it
> - The temporary file is created within the working copy, not a system
> temp dir. So the temp file perms do not really matter a whole lot.
> If the working copy contains sensitive data we can assume the user
> has made the entire tree unreadable to other users to avoid leaking
> data in the first place via working files.
> However, I doubt very much that ignoring just this one error will
> give you a usable working copy. Many svn operations attempt to create
> temporary files within the working copy, and fixing all of them might
> be a bit of work. Ignoring any such errors has to be done carefully
> because svn should not ever leak data within temporary files it creates
> outside of the working copy, especially when using a system temp dir.

Very true. I wonder if it might make sense to do a test at startup to
see if permissions are supported in the working directory and ignore
all permissions errors in the working directory iff the filesystem
would not preserve them anyway.

I also recognize that this is not a common usage scenario (I just
encountered it after using subversion for a long time), and I am not
highly inconvenienced by it. So if it warrants a bug in the tracker
with low priority, I would not be offended.

> It would nevertheless be interesting to see how far this patch gets you.
> [...]

It did get me further. The results were as follows:

$ svn co http://svn.apache.org/repos/asf/subversion/trunk testdir
A /testdir/get-deps.sh
A /testdir/NOTICE
A /testdir/LICENSE
A /testdir/Makefile.in
A /testdir/build.conf
A /testdir/win-tests.py
A /testdir/notes
A /testdir/notes/svnsync.txt
A /testdir/notes/commit-access-templates
A /testdir/notes/commit-access-templates/pmc-member.tmpl
A /testdir/notes/commit-access-templates/partial-committer.tmpl
A /testdir/notes/commit-access-templates/contrib-committer.tmpl
A /testdir/notes/commit-access-templates/full-committer.tmpl
svn: E000001: Can't set permissions on '/testdir/svn-o4bEud'
svn: E000001: Can't set permissions on '/testdir/svn-o4bEud': Operation not permitted

The backtraces to the two errors are attached.

Cheers,      |  kevin_at_kevinlocke.name   | JIM:  kevinoid_at_jabber.org
Kevin        |  http://kevinlocke.name  | IRC: kevinoid on freenode

Received on 2011-08-23 18:00:48 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.