Re: drifting IO::File offset

Given that it is not repeatable on any other OS or even in a test case the two obvious fixes are to kludge it by stashing the value of tell() or to drop the use of IO::File. I have never been able to understand why people use a module that seems to me to be a totally useless use of OO to provide syntactic sugar. For the interested the offset drift is unusual in that it varies wildly and is nothing like common buffer sizes +/- a line.

11530000    11477968    = -52032
23064612    22977360    = -87252
34602683    34593093    = -9590
46134989    46040223    = -94766
57668448    57664020    = -4428
69205366    69145548    = -59818
80739978    80667412    = -72566
92271131    92205201    = -65930
103808049    103807699    = -350
115343814    115293110    = -50704
126879579    126807910    = -71669
[download]

I think graffs idea that you may be simultaneously be mixing calls that use/bypass stdio could be at the heart of the problem.

cheers

tachyon

Comment on Re: drifting IO::File offset Download Code

Replies are listed 'Best First'.
Re^2: drifting IO::File offset by ezra (Scribe) on Sep 29, 2004 at 13:33 UTC
Thanks for posting the diffs. I calculated them, but just ended up rubbing my eyes, cursing, and getting another cup of coffee instead of doing anything useful with the info. RE: using a wrapper module, this code was written and in production with 5.00503 for a while, and back then I was using FileHandle to stash FH's as object members. It's been low in my refactoring list, up until this particular deployment.	[reply]

Replies are listed 'Best First'.

Re^2: drifting IO::File offset
by ezra (Scribe) on Sep 29, 2004 at 13:33 UTC

RE: using a wrapper module, this code was written and in production with 5.00503 for a while, and back then I was using FileHandle to stash FH's as object members. It's been low in my refactoring list, up until this particular deployment.

[reply]