Yet another attempt to solve the mystery-win32-failure cpantesters report
Peter Rabbitson [Sat, 25 Jan 2014 05:18:18 +0000 (06:18 +0100)]
While fa19e5d6 was a nice idea, its test was flawed. As seen in the fresh fail
http://www.cpantesters.org/cpan/report/137dfaf3-7bbc-1014-aec2-3d202b825c07
the writability test passed with flying colors, but the lock didn't open right
after that. The only explanation at this point is that the FS underlying this
particular dir can not create filenames starting with a dot <facepalm />
Alternatively it may have to do with the umask(0) call, but this seems even
more insane.

Thus (as unlikely as it seems) the culprit seems to be the name. Hopefully
changing it will be the end of this and we will smoke happily ever after...

Changes
t/lib/DBICTest.pm
t/lib/DBICTest/RunMode.pm
t/lib/DBICTest/Schema.pm

diff --git a/Changes b/Changes
index 3f77630..04d2994 100644 (file)
--- a/Changes
+++ b/Changes
@@ -49,6 +49,8 @@ Revision history for DBIx::Class
           the design for proper documentation and opening up)
         - Adjust exceptions in tests to accommodate changes in the upcoming
           DBD::SQLite based on libsqlite 3.8.2
+        - More robust lock file naming scheme - allow tests to work on exotic
+          MSWin32 filesystems (habitual offender being http://is.gd/iy5XVP)
         - Better diagnostics when File::Spec->tmpdir gives us crap in testing
         - Replace $row with $result in all docs to be consistent and to
           clarify various return values
index c3609b2..90d459d 100644 (file)
@@ -96,8 +96,7 @@ our ($global_lock_fh, $global_exclusive_lock);
 sub import {
     my $self = shift;
 
-    my $tmpdir = DBICTest::RunMode->tmpdir;
-    my $lockpath = $tmpdir->file('.dbictest_global.lock');
+    my $lockpath = DBICTest::RunMode->tmpdir->file('_dbictest_global.lock');
 
     {
       my $u = local_umask(0); # so that the file opens as 666, and any user can lock
index 604e71f..ab47d0c 100644 (file)
@@ -19,6 +19,7 @@ use Path::Class qw/file dir/;
 use Fcntl ':DEFAULT';
 use File::Spec ();
 use File::Temp ();
+use DBICTest::Util 'local_umask';
 
 _check_author_makefile() unless $ENV{DBICTEST_NO_MAKEFILE_VERIFICATION};
 
@@ -43,6 +44,7 @@ sub tmpdir {
     else {
       # make sure we can actually create and sysopen a file in this dir
       local $@;
+      my $u = local_umask(0); # match the umask we use in DBICTest(::Schema)
       my $tempfile = '<NONCREATABLE>';
       eval {
         $tempfile = File::Temp->new(
@@ -59,10 +61,11 @@ sub tmpdir {
       } or do {
         chomp( my $err = $@ );
         my @x_tests = map { (defined $_) ? ( $_ ? 1 : 0 ) : 'U' } map {(-e, -d, -f, -r, -w, -x, -o)} ("$dir", "$tempfile");
-        $reason_dir_unusable = sprintf <<"EOE", "$tempfile"||'', $err, scalar $>, scalar $), (stat($dir))[4,5,2], @x_tests;
+        $reason_dir_unusable = sprintf <<"EOE", "$tempfile"||'', $err, scalar $>, scalar $), umask(), (stat($dir))[4,5,2], @x_tests;
 File::Spec->tmpdir returned a directory which appears to be non-writeable:
 Error encountered while testing '%s': %s
 Process EUID/EGID: %s / %s
+Effective umask:   %o
 TmpDir UID/GID:    %s / %s
 TmpDir StatMode:   %o
 TmpDir X-tests:    -e:%s -d:%s -f:%s -r:%s -w:%s -x:%s -o:%s
index 61a4386..3aafef0 100644 (file)
@@ -165,7 +165,7 @@ sub connection {
       # which is fine since the type does not match as checked above
       undef $locker;
 
-      my $lockpath = DBICTest::RunMode->tmpdir->file(".dbictest_$locktype.lock");
+      my $lockpath = DBICTest::RunMode->tmpdir->file("_dbictest_$locktype.lock");
 
       #warn "$$ $0 $locktype GRABBING LOCK";
       my $lock_fh;