perl open +< on windows occasionally truncating file

[ngxGraz]

Hi all, I have a weird problem here that's really been screwing up a bunch of build processes.

I have a script that goes through a directory, and runs another script from it to create a modified file for each of the original, then a second call to the script (but a different function in the script) reopens the fire and stamps it with a CRC. Problem is that OCCASIONALLY one byte gets truncated from the end of the file and the stamping fails becauseo f this. I would say it happens in one of 100 files. I created a function to check when it happens (it just checks the file size_ and it appears to happen RIGHT after this call

unless( open( OUT_FILE, "<$file" ) ) {

Before we even do any reads/writes. basically I have

    CheckFileSize($file); #File is fine here
        unless( open( OUT_FILE, "<$file" ) ) {
            print "generic error msg\n";
        }
        binmode( OUT_FILE );
        CheckFileSize($file); # File is busted here

This script is running on a windows (xp) box. Anyone seen something like this?

Thanks,

G

 

[travs69]

Not sure.. but this
unless( open( OUT_FILE, "<$file" ) ) {
print "generic error msg\n";
}

is probably best as
open(OUT_FILE, "<$file" or print "Can't open $file:$!\n";
at least you'd get an idea of why it can't open it and if something else is manipulating it.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Travis - Those who say it cannot be done are usually interrupted by someone else doing it; Give the wrong symptoms, get the wrong solutions;

 

[goBoating]

Not quite enough to go on here... but, might try making sure autoflush is on. That way the print buffer is kept clean/empty.

#!perl
$| = 1; # turn autoflush on




'hope this helps

If you are new to Tek-Tips, please use descriptive titles, check the FAQs, and beware the evil typo.

 

[ngxGraz]

That wasn't a descriptive title?
We tried using OUT_FILE->autoflush( 1 ); but that didn't seem to work.
We also did another method with $| using select to change handle, seti t, then set back to the default. Neither work.

 

[KevinADC]

might be a race condition somewhere between the various scripts or you are not opening and closing files properly, very hard to say.

------------------------------------------
- Kevin, perl coder unexceptional!

 

[travs69]

well he is checking the file size while the file handle is still open and in binmode.. I'm not sure if that matters at all but You might try and close the file then run the check again.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Travis - Those who say it cannot be done are usually interrupted by someone else doing it; Give the wrong symptoms, get the wrong solutions;

 

[ngxGraz]

travs69: I do, it remains the same size. One byte smaller than usual.

Kevin: We aren't ever forking, it's all one thread.

 

[travs69]

Can you post your checkfilesize code and see if we can replicate it. You aren't using this on a drive with compression on are you?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Travis - Those who say it cannot be done are usually interrupted by someone else doing it; Give the wrong symptoms, get the wrong solutions;

 

[ishnid]

Are you using file locking at all?

 

[ngxGraz]

the checkfile size code is simply
my $size = -s "$file";

it's on an NTFS partition, no file locking, no compression.

We 'solved' the problem by using a different approach - We read the file, delete the file, then opened it for write, and rewrote it (with appropriate changes)

 

[NullTerminator]

When you switch to binmode, could it be chopping off an end of file marker? Some files may be using char 26 as an end of file marker.

If you skip the binmode call, does all work as expected?