Question

It's an old, old story: I installed TWiki on IIS and RCS doesn't work. All the rcs binaries are working fine from the command line and the path is as advised, in the environment and in TWiki.cfg. The permissions are downright lax, but still, no check-in happens for either new topics or old ones.

When I try a diff (>) link, I get the following error:

c:\inetpub\wwwroot\twiki\bin\rdiff.pl: print() on closed filehandle TWiki::Store::FILE at ../lib/TWiki/Store.pm line 1152.

If I try it with one of my new topics I get, in addition:

c:/twiki/data/Test/RCS/TestTopic6.txt,v: No such file or directory co:

I guess it's only looking for RCS because it didn't find the file in the proper location. I tried making an RCS directory - it didn't help.

I had to do a couple of strange things to get TWiki to run in the first place, namely, the fix mentioned in BizarreIis5CurrentWorkingDirectoryProblem, and putting the -T in the IIS configuration (on the .pl extension) because the Perl registry setting didn't fix it.

I've read most, if not all, the RCS topics, and they're not very encouraging. Is there any hope for RCS with IIS? Alternately, has anyone hacked up some internal version control, like in UseModWiki? I'm not looking forward to TWiki without vc, but I don't want to give up the other features.

.

• TWiki version: December 2001
• Web server: IIS 5
• Server OS: Windows 2000
• Web browser: IE5
• Client OS: Windows 2000
• Perl: ActivePerl 5.6.1

-- MaryDeMarco - 15 Jan 2002

Addendum:

I moved TWiki onto a RAID drive and the bizarre directory tweak stopped working, so I hard-coded the lib directory into the perl files. This happened to cure my closed filehandle problem, but ci is still not checking in.

-- MaryDeMarco - 16 Jan 2002

Answer

Possible Answer?

I've got it working on Win2K, IIS ? (not sure, I think it's 5... I could check with the admin if it's important) and Perl 5.6.1. It took some hacking to get past the ci problem tho. One prb was that I forgot to set the TZ variable. The other problem was with setting the LOGNAME to nobody. I've currently hacked the Perl script to set LOGNAME there instead of the env. var, not sure if that makes any difference. Of course 4 me the symptom was that the edits would take, but the rev # wasn't bumped.

You might also want to check that you set the env. vars as System variables, not User variables. I've lost count of the times where the symptom "works from command line, doesn't work from the service" is due to the fact that env. vars in NT/2K services aren't what they think you are, even if you run the svc as a certain user id.

Of course with the # of hacks I've had to do to get TWiki running on Win2K, there could easily be something else I did that explains why it works. But it can be done.

-- SteveSexton - 31 Jan 2002

Still not an answer but...

I had the same problem with not creating the ,v files. When I switched from the RCS distribution referenced here for download, to the one that is bundled in the latest version of Cygwin, that problem went away. But RCS sitll isn't working right. It seems to get confused about the file length and I think it's because of the line ending control characters. Haven't managed the proper incantation to make that go away.

-- BillKayser - 19 Feb 2002

One CygWin tip re line endings - make very sure that your file systems are all mounted as binmode, otherwise the Cygwin libraries will end up translating LF to/from CR-LF as files are read and written by RCS. I think that TWiki takes care of this for its own reads/write, but have a look for Perl binmode() calls just in case.

-- RichardDonkin - 19 Feb 2002

Eureka! Never did get the gnu distribution of RCS working and was having progress with Cygwin but it had sporadic failure with the error message about line numbers in the script not existing. I debugged and discovered cygwin rcs would truncate all appends at 1024 bytes! So if you added any text block greater than that size, it generally failed. This was in cygwin rcs 5.7-1. I just upgraded today (02/20/02) and now it works. I am also using IIS basic authentication with win2k accounts and I'm not having any permission problems. I do not have LOGNAME set. I did modify the Store.pm to write the file in binmode, as suggested, but I don't think the line endings issue was a problem anyway. Here was the mod I made. The effect was to remove all the windows 0x0d chars from line endings.

sub saveFile
{
    my( $name, $text ) = @_;
    umask( 002 );
    open( FILE, ">$name" ) or warn "Can't create file $name\n";
    binmode FILE, ":raw" ;
    print FILE $text;
    close( FILE);
}

Anyway, it works. Oh happy day...

-- BillKayser - 21 Feb 2002

Yesterday I ended up installing TWiki on Windows 2000 as well, for the first time. Quite a challenging procedure, even though I've been using Cygwin for some time and already had Apache working - the nightmare was getting RCS working, but it's all working at last!!

I also found that version of RCS for CygWin, and it is much better than the GNU-ported version. I included your patch above, as well, not sure if it was needed though.

The really essential step was to do the following in the Cygwin shell (TWiki is installed in c:/twiki):

   mkdir /twiki
   mount -b -s c:/twiki /twiki

Until I did this, any editing of the existing TWiki topics, e.g. WebHome, would corrupt them by adding CR characters, resulting in the following message (which indicates a corrupt *.txt,v file):

[Fri Feb 22 20:47:19 2002] [error] [client 127.0.0.1] co: c:/twiki/data/Know/WebPreferences.txt,v:103: edit script refers to line past end of file
[Fri Feb 22 20:47:19 2002] [error] [client 127.0.0.1] co aborted
[Fri Feb 22 20:47:19 2002] [error] [client 127.0.0.1] rcsdiff: c:/twiki/data/Know/WebPreferences.txt,v: co failed

I've also done the following to ensure that I can avoid CR-LF problems on other drives as long as I use the /c/foobar pathname format:

   mkdir /c
   mount -b -s c:/ /c

The result is the following filesystem setup:

$ mount
Device              Directory           Type         Flags
C:\cygwin\bin       /usr/bin            system       binmode
C:\cygwin\lib       /usr/lib            system       binmode
C:\cygwin           /                   system       binmode
c:\twiki            /twiki              system       binmode
c:                  /c                  system       binmode

I'll post my other experiences shortly - since it's so hard to get TWiki installed (particularly RCS) on Windows, I will probably put together a WindowsInstallCookbook. This will be a highly prescriptive but well tested set of installation steps, e.g. install TWiki in c:/twiki, put Apache in c:/apache, make these httpd.conf edits, restart Apache, then edit TWiki.cfg, then download the latest Cygwin contribs RCS and put it in /usr/bin, and so on.

I did have some early problems with lines getting doubled (which I fixed by a TWiki patch) - but this was also fixed by the binmode filesystem mounts, along with the RCS problems, so I've taken out the patch. Cygwin RCS is working well, but the default for filesystems outside the c:/cygwin hierarchy is textmode, which really messes things up for RCS.

Now that the binmode filesystem problem is fixed, I can use ActiveState as well as CygWin, and have discovered that you can use an identical TWiki.cfg for both.

-- RichardDonkin - 23 Feb 2002

I switched to cygwin RCS, but files are still not checking in most of the time. Occasionally they will, if there's already a ,v file, but new files never get one. The circumstances under which old pages will check in (i.e., increment the version number) are rather mysterious. Also, rcsdiff is throwing errors on all diff links now:

rcsdiff: no input file rcsdiff usage: rcsdiff -ksubst -q -rrev1 [-rrev2] -Vn -xsuff -zzone [diff options] file ... rcsdiff aborted 

That was from one of the files that got checked in mysteriously.

-- MaryDeMarco - 25 Mar 2002

As a first step, try uncommenting lines 51 and 52 of Store.pm so this routine reads:

sub _traceExec
{
   my( $cmd, $result ) = @_;
   TWiki::writeDebug( "Store exec: $cmd -> $result" );
}

This provides a lot more info as to exactly which RCS commands are being executed and what output they produce. Then go through each test and check the output it generates in debug.txt, posting the results here. (Have just added this to the TWikiDebugging page, but see that as well.) It would be useful to understand exactly what the problem is here, before doing anything else.

The simplest thing would be to just save your TWiki data, uninstall everything, and use the WindowsInstallCookbook from scratch - this has been tested quite a few times and does work well. I know this sounds like the classic 'just reinstall Windows', but it could take a lot of time to diagnose this sort of problem, and the WindowsInstallCookbook is well tested and doesn't take long to run through. So far, people installing TWiki on Windows have had a good success rate with this, so don't give up

Since you are using IIS, there'll be some differences, e.g. in the way you set environment variables, but the Perl, RCS and Cygwin parts are where the problems seem to be. I'll document any issues you experience with IIS, as detours from the WindowsInstallCookbook.

Let us know how you get on!

-- RichardDonkin - 25 Mar 2002

I'll try the tests, but I'm reluctant to do a full reinstall when IIS isn't really covered by the cookbook.

-- MaryDeMarco - 01 Apr 2002

• debug.txt: debug file for various failed tests

I had a look at the debug.txt file, but it doesn't seem to show any error codes - did you edit Store.pm as mentioned above? If not, it would be good to re-run the tests with this edit.

I was surprised by that, too. I did edit Store.pm.

The error about line 1152 is caused by wrong permissions on trying to write to the data/log*.txt file - either the data directory or the file is not writeable by the script.

But I looked at those logs - yesterday's in particular - and TWiki was clearly writing to them at least part of the time.

The error about creating RCS/TestTopic6.txt has happened before - the key is to not have an RCS directory in any web directory, and to make sure that $useRcsDir = "0"; in the TWiki.cfg.

Yes, I think I mentioned that above. I have no RCS directories, and that variable is set to "0". I think it's looking for an RCS directory because it can't find the file in the correct place.

As for the cookbook - it probably would save time overall to follow it... Most of your problems are not IIS related, and I do have ActivePerl working fine with Cygwin RCS, which is most of the hassle. If there are parts of your setup that are working, e.g. IIS and the way Perl is configured, you could try just redoing the other parts (e.g. remove RCS and follow the Cygwin installation and RCS parts of the cookbook).

The partway approach is what I tried. The recent, relatively identical, behavior is Cygwin RCS, not the old RCS, which is what makes me think my problems have been IIS-related all along. When in doubt, blame Bill.

Emulating the Apache part of the cookbook setup would work, i.e. setting environment variables in the System Environment that are identical to the ones in the Apache config.

Some other ideas:

• See CVS:lib/TWiki.cfg (hit the first Download link), which I have recently updated with extensive comments about how to get the $safeEnvPath right for Windows.
• Download the latest testenv from CVS:bin/testenv - this has a lot of extra code that advises on how to set things up on Windows, particularly with ActivePerl
• Make sure that diff is in your $safeEnvPath - diff is used internally by RCS, and if it's not accessible many RCS operations will fail, including checkin and rcsdiff. See RCSUnderWindowsWontCheckIn

I'll give these a shot.

Finally - if you want to live on the bleeding edge, have a look at the TWikiAlphaRelease's RcsLite, which is an all-Perl reimplementation of the RCS features used by TWiki...

-- RichardDonkin - 01 Apr 2002

Thanks. If your suggestions don't work out I'll try a clean install by the cookbook. I have a squeaky-clean test server to experiment on first, and if it falls short of full TWiki functionality again, the blame will be pinned squarely on Bill.

-- MaryDeMarco - 02 Apr 2002

Good luck - when you have the latest testenv, please attach the HTML output here, and also the TWiki.cfg file, which will help in debugging this.

-- RichardDonkin - 02 Apr 2002

Well, I tried all the suggestions (even the old binmode: raw one), and I'm in pretty much the same state as before. It turns out those mysterious checkins never checked in, either. Instead, I get one version increment in the metadata per page, and I suspect that's the only one I'll get since other people got those one-time increments, too. When I look at the rcs file, there is no increment there, and when I do a rcsdiff.pl on the pseudo-increment, no difference shows up. There's no initial checkin for new files, and an rcsdiff on those still gives the odd RCS directory in the error, although rcsdiff now works fine on the .txt,v files that do exist.

I'm attaching the testenv output and the TWiki.cfg file. As usual, I had to hard-code the lib directory into the script to get it to find TWiki.cfg, since IIS doesn't run scripts from the directory they're in. I did have the exciting experience of seeing WebIndex work for the first time, when I experimented with a c: in front of the ls command. I would have kept the c:, but it put some scary stuff at the end of the index - ten or twenty links to the piped commands themselves.

Considering how long it's taken me to get around to trying this, I don't think I'm going to have time for a clean install anytime soon. Do you think switching to Cygwin Perl might help? I noticed something in the testenv script about not using strict with ActivePerl - should I try commenting those out?

-- MaryDeMarco - 10 Apr 2002

• testenv_out.html: new testenv output

I switched to Apache, using mod_ntlm for NT authentication (see WindowsInstallModNTLM), so the problems above no longer need to be solved. The only trouble I had with Apache was from my imported data directory - I had to follow the instructions in WhyDoLinesComeOutDoubleSpaced to solve the problem, even though the drive had been mounted in binmode.

The test machine is still up, anyway, and I'm willing to try any suggestions if someone's curious about IIS.

-- MaryDeMarco - 18 Apr 2002