On Mon, Aug 22, 2011 at 04:57:37PM -0600, Kevin Locke wrote:
> Hi all,
>
> As per the bug/issue guidelines, I'm posting something that I consider
> to be a bug (but which may be contentious) to this list for
> consideration before filing a bug report.
>
> = 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.
>
> = Why I Contend it is a Bug =
> I'll be brief here, unless there is opposition: I think it is worth
> supporting working directories on filesystems without POSIX
> permissions support, where reasonable, and that the current behavior
> is highly inconvenient for such use by requiring either remounting the
> filesystem or copying the working directory to another filesystem.
>
> = Possible to Fix? =
> I've attached a backtrace to the source of the error message. Is
> there a chance it can be made non-fatal, or that the permission change
> can be avoided where not necessary?
Hi Kevin,
In this case, Subversion is trying to set permissions of a temporary
file within the working copy to the default permission bits defined
by the user's umask. The temporary file is about to be renamed to the
name of an actual working file in the working copy (i.e. this is where
checkout/update actually change the working file).
Subversion tweaks permissions in accordance with the umask to prevent
a file from having more restrictive permissions after an update than
it did before an update (e.g. changed from 644 to 600, the latter
being the default permission mode for all temporary files).
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.
It would nevertheless be interesting to see how far this patch gets you.
Index: subversion/libsvn_subr/io.c
===================================================================
--- subversion/libsvn_subr/io.c (revision 1160172)
+++ subversion/libsvn_subr/io.c (working copy)
@@ -4215,8 +4215,23 @@ svn_io_open_unique_file3(apr_file_t **file,
* case, but only if the umask allows it. */
if (!using_system_temp_dir)
{
+ svn_error_t *err;
+
SVN_ERR(merge_default_file_perms(tempfile, &perms, scratch_pool));
- SVN_ERR(file_perms_set2(tempfile, perms));
+ err = file_perms_set2(tempfile, perms);
+ if (err)
+ {
+ /* Some POSIX systems (e.g. Linux) support filesystems which
+ * do not have POSIX semantics. The OS should ideally ignore
+ * attempts to tweak POSIX permission bits on such filesystems,
+ * but in some cases we get errors.
+ * E.g. NTFS on Linux will throw EPERM. Ignore this error and
+ * leave the permission bits in their current state. */
+ if (APR_STATUS_IS_EPERM(err->apr_err))
+ svn_error_clear(err);
+ else
+ return svn_error_trace(err);
+ }
}
#endif
Received on 2011-08-23 11:03:01 CEST