Ticket #1422 (new bug)

Opened 5 years ago

Last modified 5 years ago

t/perl/Parrot_IO.t: 'not modified_since' test failing on some Win32 and Cygwin

Reported by: jkeenan Owned by:
Priority: normal Milestone:
Component: testing Version: 2.0.0
Severity: medium Keywords:
Cc: Language:
Patch status: Platform: win32

Description

In Smolder reports and discussion on #parrot, the following test failure has been reported by a Win32 user and a Cygwin user:

not ok 47 - not modified_since

#   Failed test 'not modified_since'
#   at t/perl/Parrot_IO.t line 160.

This appears to be the relevant code:

     96 # Create a file in a directory that does not exist.
     97 my $f3 = Parrot::IO::File->new
        ( tmp_file_path( 't', 'one', 'two', 'file3        .bar' ) );
     98 ok( $f3, 'file new' );
...
    158 # Status (stat info)
    159 my $time = time;
    160 ok( !$f3->modified_since($time), 'not modified_since' );

Could someone working on Win32 or Cygwin try to diagnose this?

Thank you very much.

kid51

Change History

  Changed 5 years ago by jkeenan

IIRC, there was some discussion on #parrot on Jan 31 to the effect that the problem may be specific to FAT32 filesystems. It was reported that such systems can only resolve time intervals like the ones being tested here to 2 second intervals.

Can anyone comment?

If this is true (I'm ignorant here), is there some way we can probe for FAT32?

Or are we testing the untestable?

Thank you very much.

kid51

follow-up: ↓ 4   Changed 5 years ago by coke

 http://en.wikipedia.org/wiki/File_Allocation_Table , look for "2 second".

We could probe for fat32, but we could also just cheat and just add a 2 second sleep to the test before modifying the file.

  Changed 5 years ago by doughera

Yes, there's a limit to the timing resolution. If you look at perl5's test t/op/stat.t, you'll see an amazing (or depressing, depending on your point of view) accumulation of skips and workarounds. There's even a note that for cygwin, a 3-second delay was needed (though that dates back to 2001; I don't know if it's still true.) That test can still get fooled if a Unix user is working on a FAT filesystem (yes, that does happen). Adding a sleep is about the most reliable thing you can do. Of course if you add too many sleeps throughout the test directory, you noticeably slow down the whole 'make test' process.

in reply to: ↑ 2   Changed 5 years ago by jkeenan

Replying to coke:

 http://en.wikipedia.org/wiki/File_Allocation_Table , look for "2 second".

Thanks for the link.

We could probe for fat32, but we could also just cheat and just add a 2 second sleep to the test before modifying the file.

Hmm, not sure whether that would work here. It appears to me that in this test we're not modifying the file. So I don't know where we would stick the sleep.

     96 # Create a file in a directory that does not exist.
     97 my $f3 = Parrot::IO::File->new( tmp_file_path( 
           't', 'one', 'two', 'file3        .bar' ) );
     98 ok( $f3, 'file new' );
...
    158 # Status (stat info)
    159 my $time = time;
    160 ok( !$f3->modified_since($time), 'not modified_since' );
    161 
    162 # So that the modified time will be greater than $time.
    163 sleep 1 while time() <= ( $time + 1 );

Thank you very much.

kid51

Note: See TracTickets for help on using tickets.