RE: NOT RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)

> From: Ben Reser
> Sent: Friday, 8 November 2013 11:55 AM
> On 11/7/13 4:31 PM, Geoff Field wrote:
> > Sorry to dredge up an old thread, but this issue is NOT really
> > resolved properly. (Also, I noticed a post that said that
> this would
> > be treated more seriously if it was brought up again without the
> > "RESOLVED" tag.)
>
> Not sure what you mean by this. The issue has been taken
> seriously, it's just that Apache httpd doesn't release very often.

Sorry, I sometimes fail to word things correctly. (As a native - and monolingual - English speaker, there's little excuse for that.)

I meant that in my research, I saw a post by a developer (somewhere - I no longer have a link) that referred to this thread (and a couple of others, I think) but said words to the effect of "unfortunately, all the threads mention that they're RESOLVED so it's not receiving much attention. If somebody can post again, we can raise the priority."

I'm just trying to bump the priority again, given our circumstances. Specifically, the server is a Windows Server 2003 system that's mostly under the control of a separate department to my own. It was originally set up for SVN by people who are no longer here and I'm learning as I go. There is an installation of Cygwin on the machine, but no gcc (nor any other development systems). The C: drive (where the programs reside) doesn't have a lot of spare space (but I can always drop things on the RAID drive L: where the repositories reside).

> > There's a known issue with the Apache server software
> (https://issues.apache.org/bugzilla/show_bug.cgi?id=55306)
> whereby if the directory tree being copied has a lock
> anywhere in it, the DAV component will send a 424 error. Why
> a copy should need to be concerned about a lock is a mystery.
>
> The existing mod_dav module didn't properly comply with the
> RFC for DAV that specifies that COPY methods should enforce
> If: headers in the request.

So is it just mod_dav*.so that's affected?

> Someone decided to fix this, but
> in the process they proceed to enforce some additional
> restrictions (specifically that the source and the parent of
> the source are checked for write access). In 2.2.25 and
> 2.4.6 we fixed the requirement of the parent, but missed the
> issue with the lock on the source itself. Sadly we found the
> second issue shortly after the releases and now we're waiting
> for another release cycle to get it in your hands on a release.

I look forward to release day, but I'll try not to pester people too much about it.

> > The so-called "Resolution" listed in the mailing lists here
> was simply to break or release the locks. It's not really a
> fix, just a workaround.
>
> No I'd say the resolution is to apply the patch that has been
> written to your httpd.

I agree. Breaking/releasing locks is NOT a resolution. Applying patches (or patched software) is. Is there an easy way to apply a patch on a Windows server with limited drive space for extra tools such as compilers?

> > The most recent release of Apache is 2.4.6 from July, but the last
> > activity in the bug report is from October. Any idea when the next
> > release is due? The Apache release policy
> > (http://www.apache.org/dev/release.html) doesn't seem to tell me
> > anything significant about that. (I do realise it's an open source
> > project and therefore dependant on people volunteering their time.)
>
> I don't know for sure but there was some desire to do a httpd
> 2.4.x release in October. For other reasons unrelated to
> this it hasn't happened.

You don't mean to say you actually have *lives*?? ;-)

> I see what I can do to nudge things
> along. Unfortunately, as a fairly new httpd committer, I'm
> not sure how to do the releases myself yet.

Learning curves are fun, aren't they?

> > In the meantime, we will all have to continue trying to
> remember to unlock files before attempting a branch, tag, or
> other copy. Either that, or revert to an earlier version of Apache.
>
> My suggestion would be to apply the patch to your local
> httpd. I'd meant to post some copy of the patches here on
> the list to help with this for the various mod_dav issues
> that are floating around out there and had forgotten to do
> it. I'll be sure to make a users post with these details
> here shortly.

Thanks. I could probably find the patch (or a patch) with a little more Googling. Applying it is a different story. As I said above, I don't have complete control of the server. Changing the OS would take some finagling.

> But for your immediate consumption for this specific issue.
> The following patches will work against the respective httpd versions:
> https://people.apache.org/~breser/httpd/2.2.x/patches/pr55306.patch
> https://people.apache.org/~breser/httpd/2.4.x/patches/pr55306.patch

And now I don't even have to Google.

> Hope this helps you.

Thanks. It was very helpful and informative.

Regards,

Geoff

-- 
Apologies for the auto-generated legal boilerplate added by our IT department:
- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files.