Re: trunk failing tests on Windows XP (32 bit): prop-tests.py 33, stat-tests.py 5, upgrade-tests.py 11

On Fri, Oct 1, 2010 at 3:45 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Thu, Sep 30, 2010 at 8:10 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>>> -----Original Message-----
>>> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
>>> Sent: vrijdag 1 oktober 2010 1:51
>>> To: Subversion Development
>>> Subject: trunk failing tests on Windows XP (32 bit): prop-tests.py 33,
>>> stat-tests.py 5, upgrade-tests.py 11
>>>
>>> Hi devs,
>>>
>>> The following tests fail on my machine (Windows XP 32-bit, built with
>>> VCE 2008, ra_local):
>>>
>>> - prop-tests.py 33: test properties of obstructed subdirectories
>>> svn: Can't open directory
>>> 'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdlin
>>> e\svn-test-work\working_copies\prop_tests-33\A\C':
>>> The directory name is invalid.
>>>
>>> - stat-tests.py 5: status on versioned items whose type has changed
>>> svn: Can't open directory
>>> 'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdlin
>>> e\svn-test-work\working_copies\stat_tests-5\A':
>>> The directory name is invalid.
>>>
>>> - upgrade_tests.py 11: missing directories and obstructing files
>>> svn: Can't open directory
>>> 'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdlin
>>> e\svn-test-work\working_copies\upgrade_tests-11\A\D':
>>> The directory name is invalid.
>>>
>>> They all seem to try to open some path as a directory, but it isn't a
>>> directory (but an empty file or something).
>>>
>>> Am I the only one seeing this? Is this known/normal?
>>
>> This seems to be related to the APR version you use. (Paul Burba reported
>> this same problem earlier this week).
>
> Hi Johan,
>
> Bert is correct, I saw these failure earlier this week while using APR
> 1.3.12.  All the failures occur when a file unexpectedly obstructs a
> directory.  The APR macro APR_STATUS_IS_ENOTDIR in 1.3.x does not
> handle the "ERROR_DIRECTORY 267 The directory name is invalid" that
> Windows raises in this case.  This was fixed in APR in
> http://svn.apache.org/viewvc?view=revision&revision=821306 and is in
> APR 1.4.2.

Thanks for the info. I was/am still building against APR 1.3.8, so
that explains it.

So, will 1.4.2 become the minimum supported APR version for SVN? Or
maybe a future 1.3.x release that fixes the same issue?

Or will SVN trunk be changed/fixed to cope with this? Since this
problem only appeared a week ago, it must be that something in svn
code changed to provoke this problem, right? It used to work ...

Cheers,

-- 
Johan