There is a bug in the current cvs RcsWrap.pm (v1.8) that seems to cause, or at least make worse the error ci: /data/www/twiki/CvsPlugins/EditTablePlugin/data/TWiki/EditTablePlugin.txt,v: no lock set by root.

My RcsWrap version is:

cvs status RcsFile.pm
===================================================================
File: RcsFile.pm        Status: Up-to-date

   Working revision:    1.8
   Repository revision: 1.8     /cvsroot/twiki/twiki/lib/TWiki/Store/RcsFile.pm,v

cvs log RcsFile.pm
revision 1.8
date: 2002/05/12 17:17:00;  author: talintj;  state: Exp;  lines: +7 -7
Commented out logging of RCS commands.

All of the calls to rcs commands are missing the 2>&1 at the end that will allow the error messages from ci etc to be captured. There is a comment in there that S.Knutson fixed them to capture stderr. Indeed, there is even code in sub _ci that reads:

  if( $exit && $rcsOutput =~ /no lock set by/ ) {
          # Try and break lock, setting new one and doing ci again
          my $cmd = $self->{"breakLockCmd"};

that does seem to repair the error, however this code doesn't get triggered since stderr is not captured into $rcsOutput.

The Fix

What I did was add the following after the use strict declaration at the top of RcsWrap.pm:

use vars ($captureErrors);
if ( $TWiki::OS eq "UNIX" ) {
  $captureErrors = '2>&1';
} else {
  $captureErrors = '';
}

Although use vars should be replaced by our, using our requires perl 5.6 or newer. The 2>&1 is a Bourne shell mecahnism for putting stderr (on file descriptor 2) into the output stream of stdout (file descriptor 1). It won't work if the command is executed with something other the a Bourne like shell (sh, ash, bash, ksh, zsh). So we don't capture stderr if we aren't running on Unix.

Then I made all occurrances of `$cmd...` become `$cmd... $captureErrors`. This pretty much fixed the problem as far as I can tell. I've been running with it for the last couple of hours and it seems to work. I wonder what S.Knudson's fix was?

-- JohnRouillard - 05 Aug 2002

I had some troubles with this code. Including getting it working well on windows as well as unix. I also thought I'd found a way of improving error handling by using shell error return codes, but this clearly doesn't always work. I'll take another look at this.

-- JohnTalintyre - 06 Aug 2002

JohnTalintyre, any update on this? It would be nice if this could make it into BeijingRelease. As far as I can tell, my patch should be a no-op on windows. Implementing it means that windows machines using a native windows apache rather than the cygwin apache will still be broken, but it will be fixed for Unix and full cygwin installations.

-- JohnRouillard - 26 Aug 2002

The '2>&1' apparently does work in Win2000's cmd.exe, but not on Windows NT. So it is not quite a no-op, but it sounds like your code is the basis for a fix here. People using Windows NT and ActivePerl could use the bash shell to avoid this anyway, see CookbookActivePerlSetup.

-- RichardDonkin - 17 Oct 2002

Sorry it's taken me some time to come back on this one. This above fix can be achieved by simply changing TWiki.cfg, since all cmds are fully specified there. However the original fix to this problem didn't work this way. A code snippet from CVS

            $rcsError = `$tmp`; # capture stderr  (S.Knutson)
            _traceExec( $tmp, $rcsError );
            $rcsError =~ s/^Warning\: missing newline.*//os; # forget warning
            if( $rcsError =~ /no lock set by/ ) {
                  # Try and break lock, setting new one and doing ci again
                  my $cmd = $TWiki::revBreakLockCmd;
                  $cmd =~ s/%FILENAME%/$name/go;
                  $cmd =~ /(.*)/;
                  $cmd = "$1 2>&1 1>$TWiki::nullDev";
                  my $out = `$cmd`;
                  _traceExec( $cmd, $out );
                  # Assume it worked, as not sure how to trap failure
                  $rcsError = `$tmp`; # capture stderr  (S.Knutson)
                  _traceExec( $tmp, $rcsError );
                  $rcsError = "";
            }
            if( $rcsError ) { # oops, stderr was not empty, return error
                $rcsError = "$tmp\n$rcsError";
                return $rcsError;
            }

Notice that standard out is re-directed to null and that the presence of an error is detected by there being output (on standard error). I found that this sometimes through away error messages and so instead changed to using RCS exit codes. However, I can't see why I also expected there to always be error output on standard output, although some quick tests suggest this is sometimes the case. So I'll change so that:

• Always assume failure if non zero error code
• Default option in TWiki.cfg will be to use 2>&1

-- JohnTalintyre - 20 Oct 2002

It would be useful to put the '2>&1' in a variable within TWiki.cfg, to make it simpler to turn use of capture-errors on or off. In fact, JohnRouillard's capture-errors code, above, is not a bad place to start. WinNT and Win9x/ME should have the '2>&1' turned off, but it should work on Win2000 and XP.

The ActivePerl docs (this doesn't apply to CygWin Perl, which should always support stderr redirection) describe the Win32::GetOSName function, which returns values such as Win98, Win2000, and so on. Unfortunately it seems to be broken on my copy of ActivePerl build 631, although other Win32::* functions work OK - this might be my path setup, though. Win32::GetOSVersion does work, and makes it easier to check for 'Win2000 or later'.

-- RichardDonkin - 20 Oct 2002

Variable $endRcsCmd added in TWiki.cfg that by default captures standard error.

-- JohnTalintyre - 14 Dec 2002

I changed that to be effective only for UNIX systems (includes MacOS X)

-- PeterThoeny - 15 Dec 2002

I believe it also work fine on Windows 2000. Hence I didn't try and exclude Windows automatically.

-- JohnTalintyre - 15 Dec 2002

Yes, but TWiki would fail out of the box for other Windows systems. Hmm, would be nice detect the Windows system...

-- PeterThoeny - 15 Dec 2002

A bit late, I know. But I've been doing some testing and I don't know why it was said that 2>&1 does not work on Windows NT. I've tested on Windows NT 4 Server with SP6 and it works fine. Unfortunately, I do not have an anicent enough machine to be running stock Windows NT 4 to try it on. As far as I can tell, it just doesnt work on the 9x flavors. NT/2000/XP seems to support it.

-- JasonPierce - 13 Apr 2005

Jason, it's a question of some concern that no-one has been able to complete work on the Windows implementation of the TWiki Sandbox which is slated for the Dakar release - basically because most of us are working on Linux and don't have the infrastructure to develop Windows code. The Sandbox is used to isolate TWiki core code from the system, so it's a key component. It would be great to have a Windows expert have a look at it, if you fit the description? There are existing unit tests for the Sandbox - all you need is an SVN checkout of the DEVELOP branch......

-- CrawfordCurrie - 14 Apr 2005

I'm primarily a Windows developer (though I've used unix/linux quite a bit), so I'd be glad to give any advice I can on it. Unfortunately, I'm hip deep in just getting TWiki set up for the first time for our company. It's almost done, though, and I plan to write a WindowsXPIisActiveStatePerlNativeRCS cookbook as soon as I can after that. So until I get it set up and "sold" to the boss, I'm not even sure if I'll be working with TWiki in the long term.

But after that, I'd be happy to take a look at the code. Is there any specific code snippet or question you want to ask me know? Is there a better topic for this?

On the redirections, check out my comments in InstallTipsForSpring2001Beta

-- JasonPierce - 14 Apr 2005

There is indeed. SingleEntryPointForSystemCalls. Last I heard from Richard the code does not work on Windows, though I am unable to test it.

-- CrawfordCurrie - 14 Apr 2005

Worth noting that I've been unable to get recent DevelopBranch code working on ActivePerl, so I currently think only CygWin Perl can be supported in DakarRelease... ActivePerl is good in many ways but it has significant issues that only appear in the TWiki codebase, not in simple test applications.

-- RichardDonkin - 15 Apr 2005

Can you give us some idea what the issues are?

-- CrawfordCurrie - 15 Apr 2005

Well, I was going to try the DevelopBranch with my setup, but it seems it will take me a while to be able to get SubVersion set up so I can check it out. When I get time for that, I'll report back. Just a suggestion - have a cron job create a daily tarball. This would make it a lot more accessible to the casual testers/developers.

-- JasonPierce - 18 Apr 2005

the information you're looking for is in DevelopBranch. it describes the build process by which test tarballs are created at http://develop.twiki.org/users/develop/pub/BuildDistros/index.html. it was down for a while for debugging purposes, but SvenDowideit and i have just put it back online.

-- WillNorris - 19 Apr 2005

Silly me, I just searched the page for "tarball." That's what happens when you're in a rush. Thanks for the pointer.

-- JasonPierce - 20 Apr 2005

Well, I downloaded TWikiKernel-DEVELOP-4051 and it doesn't look easy. As far I can tell, there have been some major rewrites. After getting my config all set up like my previous TWiki, I got it to load the WebHome page. The I hit edit and save. After that, every single page on the TWiki comes up blank. I still get all the template stuff like the sidebar and the Edit/Attach/etc. bar at the bottom. There's just no content in the page or in the box when you click Edit. Even though the WebHome.txt file is still there and never even got updated. Every page says "r1" now instead of "r0" like it said originally. I don't understand how editing one page could so drastically break the others, though. If there was some better debug logging, I could try to track it down and see where it's blowing up. But as it is, it's pretty inaccessible. I guess I'm going to have to just use the most recent stable and go from there.

I don't understand why things just wouldn't work on ActivePerl. I could understand if some things might be slightly different than on other OSes, since every OS can be slightly different. But I don't understand why it would be a lost cause to try to make it work in a flexible setup in Windows.

-- JasonPierce - 20 Apr 2005

There is no way for an edit of one topic to affect any other topic. The only function that allows that is rename, and I assume you didn't rename any topics?

I wouldn't waste time building on Cairo; like you say, there have been a lot of changes.

I've never heard of or seen anything like you describe; however if you switch on TRACE in the Sandbox module, you will get a log of every system call the code makes (in your apache error log).

-- CrawfordCurrie - 21 Apr 2005

Well, I've already finished making Cairo work perfectly with Windows+ActivePerl+native RCS. You're not saying I shouldn't build pages under Cairo, are you? I'm assuming that the twiki syntax isn't being changed. Am I wrong on this? As long as the syntax is stable, there's no real reason for me not to continue building under Cairo.

I'll try to do more testing on DEVELOP as soon as I can make some time.

-- JasonPierce - 21 Apr 2005

the syntax is stable.

If cairo works perfectly (with the sandbox) then give me the sandbox code; it's a job of a few minutes to port the changes to DEVELOP.

-- CrawfordCurrie - 21 Apr 2005