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
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