in reply to binmode layer and seek

That's what IO-Layers generally do - they change the read and written data on the fly.

The :crlf IO layer adds a cr for each lf, and strip it again when you read it.

So a "raw" file handle without such a layer will read a different result, thus producing a different MD5 sum.

If you want to build checksums, always read the data as binary, without any additional IO layers.

BT seek is totally unrelated here - if you close the file, and open again with the :crlf IO layer you'll get the same results as with seek(0,0).

Replies are listed 'Best First'.
Re^2: binmode layer and seek
by ftumsh (Scribe) on Jul 08, 2008 at 13:31 UTC
    Ah I see. Thanks for the explanation. What I didn't understand was why the layer was working for one thing and not another. I've had a look at the MD5.pm and it's using XSloader, which I presume means the MD5.pm is using C and therefore bypassing the layer. Having said that, if it was bypassing the layer I'd expect it to give the correct result. John
      MD5.pm doesn't bypass anything. If it would, you'd get the same result for all three outputs.

      Here is, in more detail, what happens:

      • You open a file, and apply the crlf IO layer.
      • You write a "\n" to that file. The crlf layer converts that to CRLF
      • MD5.pm reads from the very same filehandle. That means that the CRLF is converted to "\n" again upon reading. MD5.pm interprets that as binary data, and thus as LF.
      • You close the file, and open it again, this time without any layer
      • MD5.pm reads from that file, and this time the line ending comes out as CRLF, because no IO layer converts anyting. MD5.pm computes a hash, which is different than before because the source data is different