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

Re: svn commands fails on write-only files or directories access

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2006-07-28 00:14:23 CEST

Alexander Thomas wrote:
> While trying to svn add a write-only file, I got error message like
> subversion/libsvn_subr/io.c:2473: (apr_err=13)
> svn: Can't open file 'foo': Permission denied

(but it has actually been added to the WC)

That's a bit ugly: ideally the operation would fail atomically. However,
that's a fairly unusual thing to attempt, and the symptoms seem safe enough in
my trials: it shows up as "added" in "svn status", and can be reverted, and
cannot be committed. The user could well be confused but I don't see any
danger there. Therefore I don't think it's an important bug, but certainly it
would be nice to have a cleaner failure mode (i.e. not actually marking the
item as added).

The reason it fails in this way is because of non-atomic WC handling. The
function libsvn_client/add.c:add_file() first calls svn_wc_add2() which adds
the file, and then goes to work out what properties it should have, and tries
to read the file for MIME type detection. Ideally we'd work out the properties
first, and then use some form of "svn_wc_add()" function that could add the
file with its properties in a single operation.

Perhaps the keen WC people would like to take a look at this...

- Julian

> Initially I was of the impression that the operation failed, but 'svn
> status' says operation succeed. I think users will get confused with the
> above error message, because error looks more like a failure than a
> warning.
> svnadmin create /tmp/repos
> svn co file://tmp/repos /tmp/wc
> cd /tmp/wc
> touch foo
> chmod -r foo
> svn add foo
> svn st foo
> Same happens while adding a write-only directory, but a --non-recursive
> add or status can fix this.
> I suspect this is because svn tries to open the write-only
> file/directory and a quick scan confirms it too. Can any one suggest a
> better solution for this problem.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 28 00:13:48 2006

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.