Question

I followed the WindowsInstallCookbook, which worked fine for most things.

But there seems to be a bin/text mode problem with attachments. When I upload pictures, the files arrive in the correct locations and versioning seems to work. But the files arrive corrupted - seems to be a bin/text mode problem.

When I copy the pictures 'by hand' to the server directory, everything is ok.

• TWiki version: 2001/12, Perl and RCS on CygWin
• Web server: Apache 1.3.23 Win32
• Server OS: Windows 98 SE
• Web browser: Mozilla 0.98, Netscape 4.7, Internet Explorer 5.5
• Client OS: Windows 98 SE

-- WolframJahn - 04 Mar 2002

Answer

First of all, is your twiki directory, and particularly the pub directory, on a Cygwin binmode filesystem? Try doing, from a Cygwin shell:

   perl -e 'print "hello\n"' > /twiki/pub/foo
   cat -v /twiki/pub/foo
   rm /twiki/pub/foo

You should not see ^M in the output if you are using binmode. Also do mount and compare with the output in the cookbook.

This is all ok. (As I have written, I followed the cookbook :-)

Did you install/upgrade Perl as part of the installation?

Yes

Are you using Cygwin Perl, and if so which version?

This is perl, v5.6.1 built for cygwin-multi

I just re-tested image attachments on my Windows TWiki installed using the cookbook, and they worked OK using Cygwin Perl and ActivePerl.

What version of CGI.pm are you using?

$CGI::VERSION='2.752';

Try upgrading CGI.pm - see AttachedImageMangled, where this helped. Just launch cpan then type install CGI. Or just re-install Perl from the Cygwin setup.exe tool.

-- RichardDonkin - 04 Mar 2002

Thanks for the updates - the only thing I can suggest is to upgrade CGI.pm to version 2.78. Although I'm also using 2.752, it's possible 2.78 has some bugfixes that are relevant to Win98 (I'm using Win2000).

Another directory to check is Cygwin's /usr/tmp, which is hard coded into CGI.pm for the uploaded temporary file.

By the way, including the $Id: string has resulted in an interesting TWiki bug, visible in the $CGI::revision line above - the Id string has been substituted by RCS, based on this topic name... not serious here, but should be logged as a bug.

-- RichardDonkin - 04 Mar 2002

Thats interesting.

When I install CPAN CGI, I get:

$CGI::revision = '$Id: TwikiOnWindowsBinaryAttachments.txt,v 1.14 2002/06/15 15:33:00 RichardDonkin Exp nobody $';
$CGI::VERSION='2.80';

wolfram@PABLO /lib/perl5/5.6.1
$

But installing perl with cygwin I update instead

$CGI::revision = '$Id: TwikiOnWindowsBinaryAttachments.txt,v 1.14 2002/06/15 15:33:00 RichardDonkin Exp nobody $';
$CGI::VERSION='2.752';

wolfram@PABLO /lib/perl5/5.6.1/cygwin-multi
$

So I seem to have a problem understanding cygwin.

Unfortunately, I don't know nearly nothing about cygwin by now.

Maybe I should rtfm.

• How to tell cygwin which perl to use
• or how to tell cpan where to update perl
• or how to tell apache where to find perl

Oh I love Windows. It works or it does not. In Unix environment, there are always by far too much ways for me to get things fixed somehow...

Just kidding

-- WolframJahn - 04 Mar 2002

Even if you have more than one Perl installed (e.g. I have ActivePerl as well as Cygwin's), the choice of which to use is driven by:

• The shebang line on CGI scripts - always use a full pathname here, c:/cygwin/bin/perl for the Cygwin perl a la cookbook
• The Cygwin path (for any cygwin apps, e.g. the bash shell) - just do 'type perl' or 'which perl', which normally report /usr/bin/perl

Within a given Perl, it seems that different package versions can be loaded - this is probably because Perl 5.6.1 is multithreaded, but not all packages are thread-safe, hence the cygwin-multi directory. Previous versions of Perl didn't have this issue to deal with.

To see the actual version loaded, do this from the Cygwin shell:

perl -e 'use CGI; print $CGI::VERSION;'

Also, try including this code at the top of one of the TWiki scripts to see exactly which CGI.pm version it is loading. (I've added it to testenv but that's not yet uploaded.)

-- RichardDonkin - 05 Mar 2002

Thanks for you patience. You will need more

Unfortunatelay, even with perl CGI 2.80 the same thing happens, exactly as described in AttachedImageMangled.

I dont know what do try next.

-- WolframJahn - 05 Mar 2002

If possible, attach to this topic one of the files that gets corrupted, as it may be data dependent - also, which file types get corrupted? I've tried JPGs and GIFs (which have ^Z characters after about 2K, and therefore break easily with text-mode uploads), but I think PNGs are more sensitive to this.

Does this problem happen with both browsers? What are the size of files before and after upload, and of the temp file vs the final binary file?

On the assumption that it's not a CGI.pm bug, try the following code which makes sure that the file is copied in binmode from the temp file to the final location in /pub. This is taken from perldoc File::Copy= etc.

At the top of Store.pm:

use FileHandle;

Then at line 772, change the copy command to be:

    # copy($theTmpFilename, $newFile) or warn "copy($theTmpFilename, $newFile) failed: $!";
    my $TMPFILE = FileHandle->new($theTmpFilename,"r");
    my $NEWFILE = FileHandle->new($newFile,"w");
    binmode $TMPFILE;
    binmode $NEWFILE;
    copy($TMPFILE, $NEWFILE) or warn "copy($theTmpFilename, $newFile) failed: $!";

If this doesn't help, it is probably a bug in CGI.pm (fairly unlikely) or Cygwin (possible). The code above works OK on Windows 2000 with ActivePerl and Cygwin Perl, but should not be necessary as File::Copy is meant to be a binary copy. I can't see how the original code could go wrong, really...

One other thing to try is to put in a system ("ls -l $theTmpFilename"); about here, and the same for the new file once created (and try this with the original code to see what happens - in fact, try this before the above code change).

Finally, try installing ActivePerl, in case this is an issue with Cygwin on Win98 (not a very common combination) - this works fine with TWiki as long as you follow the hints in the cookbook, and you can just switch over the upload script for test purposes.

-- RichardDonkin - 05 Mar 2002

---

Two new facts:

• first the good one: (binary) Attachments now work fine here.
• and the bad one: I don't know why.

What I did:

• in an anger, I deleted everything dealing with cygwin and twiki, and started from scratch.
• Then I tried an ActivePerl installation, but didn't even get versioning to work.
• Then again I followed your cookbook, and ZAP SWOOSH BANG everything worked.

My CGI.pm is still version 2.7.52

"interesting...", as the worlds best game would tell.

Thanks for your patience, and, again, for your cookbook. If I can be of any help further on, feel free to contact me again.

-- WolframJahn - 10 Mar 2002

Thanks for the update, and glad you are now up and running! I'm urious as to why it didn't work the first time, but maybe there were some slight differences in how you did the second install.

-- RichardDonkin - 13 Mar 2002

I ran into the identical problem initially described above. I followed the cookbook, and image failed to upload properly. (They were being text-transcoded.) I did not have to delete my cygwin installation. Since my initial installation called for "MS-DOS" / (aka "textmode") returns, and I then attempted to re-install with "UNIX" / (aka "binmode") returns, the Cygwin registry reflected the old values for "textmode".

You can verify this problem by typing '''mount'''. It would return:

C:\cygwin\bin on /usr/bin type system (textmode)
C:\cygwin\lib on /usr/lib type system (textmode)
C:\cygwin on / type system (textmode)

These must say "binmode" for upload to work properly.

Attempts to change the mode would fail, because the cygwin environment is running. Hence, one must dive into the Registry. The 'flags' were set to dword:00000010 which meant "textmode". You must change the 'flags' key value to dword:0000000a as shown below for "binmode".

REGEDIT4
[HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/twiki]
"native"="c:\\twiki"
"flags"=dword:0000000a

[HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/c]
"native"="c:"
"flags"=dword:0000000a

[HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/]
"native"="C:/cygwin"
"flags"=dword:0000000a

[HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin]
"native"="C:/cygwin/bin"
"flags"=dword:0000000a

[HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib]
"native"="C:/cygwin/lib"
"flags"=dword:0000000a

If you are installing a clean Cygwin installation, be sure you check "UNIX" returns. Otherwise, you may need to modify the key values above, as shown.

-- MikeBytnar - 12 Jun 2002

Thanks for the clarification - I suspect this happens because the /var/tmp and /tmp directories are used for temporary storage when uploading files. For those who don't want to edit the registry, the simplest solution is probably to uninstall and re-install Cygwin. This is exactly what Wolfram did, above, and explains why his installation ended up working.

I've updated the WindowsInstallCookbook to highlight this (there was already a comment about the need to use Unix as the default file type when installing, but I've emphasised its importance to attachment uploads).

-- RichardDonkin - 15 Jun 2002