Re: RC1 uploaded to PAUSE, and indexing problems 
On Nov 18, 2007, at 12:51 PM, Dominic Dunlop wrote:

>
> On 2007â11â18, at 11:39, Jos I. Boumans wrote:
>>> ../lib/Archive/Tar/t/02_methods.t, ../lib/Archive/Tar/t/ 
>>> 04_resolved_issues.t: These two don't fail if I run the tests on  
>>> a UFS partition, so I suspect that the problem is something to to  
>>> with Apple's default case-preserving-but-case-folding HFS+. A  
>>> quick look at the test code leaves me bemused. Jarkko, what type  
>>> of filesystem did you do your build in? Copied to Jos Boumans,  
>>> maintainer of Archive::Tar in the hope that a bell rings.
>>
>> No bell, but can you show the verbose output of the test run,  
>> including which tests fail?
>> Without information, it'll be near impossible to track down.
>>
> Thanks for the quick response. Just giving you the chance to say  
> "Oh yes. I already know about that." Full output attached.

Didn't know about this yet, but let's see if we can track down what's  
going on.

There's in total 2 test failures. Here's the first:

ok 84 - Object created
ok 85 - The object isa Archive::Tar
ok 86 - Adding files
ok 87 -    Proper name

not ok 88 -    Proper type
#   Failed test '   Proper type'
#   at ../lib/Archive/Tar/t/02_methods.t line 251.
#          got: ''
#     expected: '1'
ok 89 -    Content OK
ok 90 -    File found in archive
ok 91 - Added files to secondary archive

Obviously, we're not getting the type we expected. Here's the  
relevant test code
(t/02_methods.t:247 and onwards):

         SKIP: {
             skip( "You are building perl using symlinks", 1)
                 if ($ENV{PERL_CORE} and $Config{config_args} =~/ 
Dmksymlinks/);

             is( $files[0]->is_file, 1,
                                     "   Proper type" );
         }

Could you print out the value for it's type? do so using:

   warn $files[0]->type;

Perhaps the UFS is interfering with the filetypes =/
Below the sig you see what every value means (taken from  
Archive::Tar::Constants)


The second test failure:

ok 30 -    Extracting in insecure mode
Could not update timestamp at ../lib/Archive/Tar/t/ 
04_resolved_issues.t line 152
ok 31 -        File extracted
not ok 32 -        File '../04_resolved_issues.t.4219' exists
#   Failed test '       File '../04_resolved_issues.t.4219' exists'
#   at ../lib/Archive/Tar/t/04_resolved_issues.t line 154.
1..32
# Looks like you failed 1 test of 32.

This one is a bit trickier to track down. You'll need to run this  
through the debugger.
Continue until line _145_ in 04_resolved_issues.t which reads:

         ok( $tar->extract_file( $out_file ),
                                 "       File extracted" );

and then set a breakpoint on:

   Archive::Tar::_extract_file

Every operation in that sub should be checked for success and report  
an error if it fails.
However, it doesn't fail until we try to update the timestamp (which  
is non-fatal).

Could you check how far along the operations are still successful?  
And perhaps see why
no errors are being printed?

If you need any help, please let me know -- I unfortunately don't  
have access to a UFS
filesystem :(

--
	Jos Boumans

	'Real programmers use "cat > a.out"'

use constant FILE           => 0;
use constant HARDLINK       => 1;
use constant SYMLINK        => 2;
use constant CHARDEV        => 3;
use constant BLOCKDEV       => 4;
use constant DIR            => 5;
use constant FIFO           => 6;
use constant SOCKET         => 8;
use constant UNKNOWN        => 9;
use constant LONGLINK       => 'L';
use constant LABEL          => 'V';



