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

switch-tests.py 17 FAILs with svn 1.4.0_RC1 on fc1+nfs

From: Lieven Govaerts <lgo_at_mobsol.be>
Date: 2006-06-04 10:49:45 CEST

Hi,

I have a problem when running 'make check' on a Fedora Core 1 vps with the
latest RC of svn 1.4.0. It shows that the test 'switch_tests.py 17' fails.
Rerunning 'make check' and manually running switch test 17 gives the same
result.

The error I get is: "'A/mu' expected to be read-only after having had its
svn:needs-lock property set".

When looking through the code of test 17 (= refresh_read_only_attribute),
the failure seems to occur at line 1017:

  # The file on which svn:needs-lock was set is now expected to be
read-only.
  if os.access(mu_path, os.W_OK):
    raise svntest.Failure("'%s' expected to be read-only after having had "
                          "its svn:needs-lock property set" % mu_path)

So clearly it checks if it can write to the file A/mu and that succeeds, so
an exception is raised.

I extracted the os.access call and tested it in both python 2.2.3 and python
2.4.1. Both tests show that this call doesn't work on my system:

(user root)
# cd /tmp/
# touch test
# chmod a-w test
# stat test
  File: `test'
  Size: 0 Blocks: 0 IO Block: 4096 regular empty
file
Device: 23h/35d Inode: 34652169 Links: 1
Access: (0444/-r--r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2006-06-04 10:39:29.000000000 +0200
Modify: 2006-06-04 10:39:29.000000000 +0200
Change: 2006-06-04 10:39:31.000000000 +0200

# python
Python 2.2.3 (#1, Oct 15 2003, 23:33:35)
[GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.access("test", os.W_OK)
1
>>>

# python24
Python 2.4.1 (#1, Jun 21 2005, 00:37:24)
[GCC 3.3.2 20031022 (Red Hat Linux 3.3.2-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.access("test", os.W_OK)
True
>>>

Reading through the documentation of the os.access call (in
http://docs.python.org/lib/os-file-dir.html) I see this note:
"Note: I/O operations may fail even when access() indicates that they would
succeed, particularly for operations on network filesystems which may have
permissions semantics beyond the usual POSIX permission-bit model."

My FC1 system is a Virtuozzo Virtual Private Server, with an NFS mounted
ReiserFS file system, which is probably the reason why the test fails. It's
also mounted with user and group quota activated.

Does anyone know better alternatives for the os.access call? I see that it's
only used in that particular test, maybe it's not that difficult to change
it with something that works even on my exotic system.

regards,

Lieven.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 4 10:54:26 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.