Bug #31544 for PAR: PAR::read_file output not identical to archive contents

Fri Dec 14 15:33:04 2007 1197600783 [...] noid.net - Ticket created

Subject:	PAR::read_file output not identical to archive contents
Date:	Fri, 14 Dec 2007 12:32:30 -0800
To:	bug-par [...] rt.cpan.org
From:	Tor Perkins <1197600783 [...] noid.net>

Hello, Thanks for PAR, it's awesome!! I am experiencing what I think may be a bug... When I use pp to add an additional file to a PAR executable, things seem to work properly, e.g.: pp -a notepad.exe -o my_prog.exe my_prog.pl If I manually extract notepad.exe from the resulting my_prog.exe archive (using WinZIP or something), the result is identical to the original (no problem)... If, however, I run my_prog.exe which uses the my_prog.pl script contained in the archive to extract the file, I get a file that's similar, but it's larger than the original file, e.g.: dir notepad*.exe 12/06/1999 08:00p 50,960 NOTEPAD.EXE 12/14/2007 12:02p 51,021 notepad2.exe Here's what my script looks like: # my_prog.pl use PAR; my $content = PAR::read_file('notepad.exe'); open(OUT,'>notepad2.exe'); print OUT $content; close out; I apologize if I am doing something wrong. I greatly appreciate your consideration of my issue and value your time. Thanks! - Tor PS - Here's some other details for my system: I'm running ActivePerl-5.8.8.822-MSWin32-x86-280952.msi on Win2K. I have these module versions installed: ActivePerl-Config 1.02 ActivePerl-DocTools 2.1 ActivePerl-PPM 4.1 ActiveState-RelocateTree 1.4 ActiveState-Scineplex 1.01 ActiveState-Utils 2.3 Archive-Tar 1.32-r1 Archive-Zip 1.23 Compress-Zlib 1.4201 Config-IniFiles 2.37 DBD-SQLite 1.13 DBI 1.58 Data-Dump 1.08 Digest-HMAC 1.01 Digest-MD2 2.03 Digest-MD4 1.5-r1 Digest-SHA1 2.11 File-CounterFile 1.04 File-Which 0.05 Font-AFM 1.19 Getopt-ArgvFile 1.11 HTML-Parser 3.56 HTML-Tagset 3.10 HTML-Tree 3.23 IO-String 1.08 IO-Zlib 1.04 LWP 5.806 MD5 2.03 MIME-Base64-Scripts 1.00 Math-BigInt-FastCalc 0.13 Module-ScanDeps 0.57 Net-DNS 0.49 Net-Syslog 0.03 PAR 0.976 PAR-Dist 0.25 PAR-Packer 0.976 Parse-Binary 0.10 Perl 5.8.8.822 SOAP-Lite 0.55-r1 Tcl 0.89-r2 Term-ReadKey 2.30 Term-ReadLine-Perl 1.0302-r1 Text-Autoformat 1.13 Text-Reform 1.11 Tk 804.027-r6 Tkx 1.04 URI 1.35 Unicode-String 2.09 Win32-API 0.41 Win32-AuthenticateUser 0.02 Win32-Exe 0.09 Win32-GUI 1.03 XML-Parser 2.34-r1 XML-Simple 2.16 libwin32 0.26-r4

Sat Dec 15 04:34:27 2007 smueller [...] cpan.org - Correspondence added

Dear Tor, On Fri Dec 14 15:33:04 2007, 1197600783@noid.net wrote: Show quoted text

> I am experiencing what I think may be a bug...

yes, this does sound like a bug. I'm just not exactly sure where. :) Show quoted text

> When I use pp to add an additional file to a PAR executable, things > seem to work properly, e.g.: > > pp -a notepad.exe -o my_prog.exe my_prog.pl > > If I manually extract notepad.exe from the resulting my_prog.exe > archive (using WinZIP or something), the result is identical to the > original (no problem)...

Okay, so there is something going on during extraction. Show quoted text

> If, however, I run my_prog.exe which uses the my_prog.pl script > contained in the archive to extract the file, I get a file that's > similar, but it's larger than the original file, e.g.: > > dir notepad*.exe > > 12/06/1999 08:00p 50,960 NOTEPAD.EXE > 12/14/2007 12:02p 51,021 notepad2.exe > > Here's what my script looks like: > > # my_prog.pl > > use PAR; > > my $content = PAR::read_file('notepad.exe'); > > open(OUT,'>notepad2.exe'); > print OUT $content; > close out; > > I apologize if I am doing something wrong. I greatly > appreciate your consideration of my issue and value your time.

My hunch is that this is a line-ending issue. You're using Windows which uses a line-ending which is really two characters (\012\015 if I remember correctly) whereas Unix/Linux line ending only uses one character. Therefore, when writing binary data to files, one has to explicitly request it to work in "binmode" using the "binmode(OUT);" function in order for the automatic line-ending-conversion-stuff not to happen. Hence, I think you would not see the size difference if you added an explicit "binmode(OUT);" after the open() line. I'm not entirely sure, of course and I cannot test it for the lack of a Windows computer. If this doesn't fix the issue, the please try this again with a short text file (containing multiple lines) and reply with the original and modified text files attached. Thank you! Best regards, Steffen

Sat Dec 15 04:34:33 2007 The RT System itself - Status changed from 'new' to 'open'

Tue Dec 18 20:23:36 2007 1197600783 [...] noid.net - Correspondence added

Subject:	Re: [rt.cpan.org #31544] PAR::read_file output not identical to archive contents
Date:	Tue, 18 Dec 2007 17:23:02 -0800
To:	bug-PAR [...] rt.cpan.org
From:	Tor Perkins <1197600783 [...] noid.net>

Your "binmode(OUT);" suggestion worked! After consulting the perl documentation on this function, I think that this is not a bug and I should have known better. In my defense, I would say that I usually do not use systems that distinguish between text and binary modes... Thanks very much for your help! - Tor On Sat, Dec 15, 2007 at 04:34:34AM -0500, Steffen M??ller via RT wrote: Show quoted text

> > My hunch is that this is a line-ending issue. You're using Windows which > uses a line-ending which is really two characters (\012\015 if I > remember correctly) whereas Unix/Linux line ending only uses one > character. Therefore, when writing binary data to files, one has to > explicitly request it to work in "binmode" using the "binmode(OUT);" > function in order for the automatic line-ending-conversion-stuff not to > happen. Hence, I think you would not see the size difference if you > added an explicit "binmode(OUT);" after the open() line. I'm not > entirely sure, of course and I cannot test it for the lack of a Windows > computer. > > If this doesn't fix the issue, the please try this again with a short > text file (containing multiple lines) and reply with the original and > modified text files attached. Thank you! > > Best regards, > Steffen

Wed Dec 19 02:58:42 2007 smueller [...] cpan.org - Correspondence added

Hi Tor, thanks for following up on this. I'm marking the issue as resolved. Best regards, Steffen

Wed Dec 19 02:58:46 2007 smueller [...] cpan.org - Status changed from 'open' to 'resolved'