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

[Julian Foad <ju...@btopenworld.com>]

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

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

[Erik Huelsmann <eh...@gmail.com>]

On 7/28/06, Julian Foad <ju...@btopenworld.com> wrote:
> 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...

I did. In r20895, I reordered operations. That commit can be
backported to 1.4 and even 1.3. I agree that we probably want a
svn_wc_add3() which also adds props, but since that would be an API
change, it's not the right time to implement that now (it would become
available in 1.5 at the earliest...)

bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Jared Hardy <ja...@gmail.com>]

Alexander Thomas wrote:	
> While trying to svn add a write-only file, I got error message like

On 7/28/06, Jared Hardy <ja...@gmail.com> wrote:
> Who cares if the file is Read-Only locally?

So based on this line, I obviously mis-read earlier e-mails in this
thread. Sorry.
I was browsing other e-mails, here and on TortoiseSVN's list (one from
jwalter@karneval.cz reminding me of personal frustrations), with
similar stories more akin to a read-only type situation, saw the word
"fail", and went off. I'll try to target my frustrations a bit better
next time.  <:o

Sorry,
Jared

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Jared Hardy <ja...@gmail.com>]

> That's a bit ugly: ideally the operation would fail atomically.

<rant>

Why does this operation need to fail? Reading through the mailing list
and archives, it seems the answer to a lot of problems is "fail
atomically", when the real obvious answer for any frequent user should
be "handle gracefully". Who cares if the file is Read-Only locally?
Add is just copying the file to the repository, so why should it need
write access to the WC file for this operation? If it needs write
access for the operation, shouldn't it attempt a chmod or the like
before failing?
    All such failures seem ugly to me. Even worse are the failures
like "file locked" (meaning OS local-file lock, not repository lock,
which the message never makes clear), "failed to move blah.tmp"
followed by "cleanup failed, failed to move blah.tmp [again]". Or the
most stupid of all: "local fine not versioned" on an update attempt to
a file lacking WC status information, and rather than just leaving the
file alone and updating WC status, it fails the whole Update
non-atomically, sometimes requiring a follow-up cleanup to get
anything done again. Why is failure always the answer here?
    I often work around these things with my own wrapper tools. I get
a log list from WC+1 to HEAD, renaming all files on the list to
*.~bak~, renaming back unless unversioned, in which case I rename
after update which has the same net effect as a WC-status-only update.
If I can't rename, there's obviously some kind of OS local file lock
issue, so I rename pending back then fail the whole Update operation
and let the user know about the locked file, *before* getting into a
state requireing a cleanup. I don't understand why svn client commands
can't do the same.
    And these are just Update errors. Commit errors are even more
annoying. "Commit failed -- file not latest" type errors are
ridiculous. Just update the thing for me, and only bother me if
there's a merge conflict. Even if certain users don't want this to be
the default behavior (I don't know any personally), it should be at
least a config option.

I swear if the repository and bidirectional network model wasn't so
great, I would have given up on the svn client last year.

</rant>,
Jared


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