Question

When I create a new topic, the version control seems to work fine, and sets the version to 1.1. However, if I (or someone else) edits the topic, then the topic gets edited, but the version number never updates. The same thing happens with trying to edit existing topics.

I removed all the old versioning files to try to fix the 'nobody' issue, and it seemed to work. The files are locked by the last person who edited it. Just new revisions never are recorded.

• TWiki version:
• Web server: IIS
• Server OS: Win2K

-- AlexKilpatrick - 06 Jul 2001

I get the same effect on Win NT SP6a, Apache 1.3.14 running as SYSTEM, ActivePerl 5.6.1 build 628, RCS 5.7. Tracing the RCS output tells me that ci tries to create a new version 1.5 but does not succeed as the the following rlog still reports version 1.4:

Executing: E:/bin/ci.exe -x,v -l -mnone -t-none -w'RalfHandl' E:/twiki/data/Main/RalfHandl.txt
E:/twiki/data/Main/RalfHandl.txt,v  <--  E:/twiki/data/Main/RalfHandl.txt
new revision: 1.5; previous revision: 1.4
Executing: E:/bin/rlog.exe -x,v -h E:/twiki/data/Main/RalfHandl.txt

RCS file: E:/twiki/data/Main/RalfHandl.txt,v
Working file: E:/twiki/data/Main/RalfHandl.txt
head: 1.4
branch:
locks: strict
		  SYSTEM: 1.4

Submitting the above ci from a command line tells me:

E:/twiki/data/Main/RalfHandl.txt
E:/twiki/data/Main/RalfHandl.txt,v  <--  E:/twiki/data/Main/RalfHandl.txt
new revision: 1.5; previous revision: 1.4
done

i.e. an additional line stating done. So ci seems not to finish its work when called from TWiki.

-- RalfHandl - 09 Jul 2001, looking forward to an answer

Seems I'm having the same trouble running NT: When adding a new topic, the ,v file does not get created. When I issue the command from a dosbox, it does get created. Weird....

Since it seems to be solved by the new release, I'll have a go with the beta if I can get it.

-- HansDonner - 04 Aug 2001

Answer

The RCS problem disappeared after upgrading to TWiki20010701beta, so the simple answer seems to be "wait for the TWikiReleaseSpring2001".

-- RalfHandl - 10 Jul 2001

Lots of people have the Dec2000 and March beta releases working fine, so I doubt that's the problem. Have a look at the various TWiki pages on Windows support (see WebSearch and use a topicname search).

-- RichardDonkin - 10 Jul 2001

Hmm. On a UNIX box I would say this looks like a permissions problem and would ask who owns the RCS and resulting txt files? What permissions do the files have?

On a Windows box, if the problem only affects files such as Web* then it is because the locks shipped with TWiki belong to nobody not system. See TWikiOnWindows.

-- MartinCleaver - 16 Jul 2001

Sorry, it was not that simple.

I locked the files manually as SYSTEM as described in TWikiOnWindows. Also the SYSTEM account had full access to the file system where TWiki was installed. Tracing the RCS calls showed that RCS started to execute but seemingly did not finish. There were no hanging processes or anything like that, RCS just died while checking in.

Running Apache under my user account had the same effect: RCS died while trying to check in. Submitting the traced RCS commands from a command line window worked.

Changing nothing in the configuration and just installing TWiki20010701beta made the problem disappear. The calls to RCS are handled differently in the new release, may be some subtle Perl/Windows interaction problem is now circumvented. I had no time to investigate these subtleties.

-- RalfHandl - 17 Jul 2001

Where did you get RCS? Hey, well, I guess it doesn't matter now. Roll on the Spring Release.

-- MartinCleaver - 25 Jul 2001

Can you give me any hints as how to get the TWiki20010701beta to work? I can't seem to figure out what goes where, etc...

-- MichaelCodanti - 30 Jul 2001

Since I ran also into the described problem using the latest production release I tried using the latest Beta release (aug 3). Guess what, still've got troubles with ci.exe

Update: I was thinking. Apache runs as a Service using the system account. I logon using my network account (also when I'm offline - it's a laptop). Is this perhaps a reason why it won't work?

-- HansDonner - 04 Aug 2001

Checked that the Sytem account has all the rights. Even tried running Apache as local user (with the rights described in the documentation of Apache), even that didn't help. The "done" part is still missing with me... Investigating further...

Update: Created local account and set apache server to use this account. Logged myself in with that account. Both cygwin/bin and rcs are in the path. Tried creating new page withh Twiki: the rcs file is not created. Executed the same command from the command line and that did work. I checked the TWikiOnWindows and other Windows and/or RCS related pages over and over again, but couldn't find anything different. Still it looks like I'm missing something.

Capturing the output:

c:/app/rcs/ci.exe -x,v -l -m"none" -t-none -w"guest" c:/web/twiki_beta/data/Test/TestTopic1.txt 1>>/temp/stdout 2>>/temp/stderr

Result of the output files: stdout: empty; stderr:

c:/web/data/twiki_beta/data/Test/TestTopic1.txt,v  <--  c:/web/data/twiki_beta/data/Test/TestTopic1.txt

Seems like ci stops after this (??)

Running the same from the cmd line:

C:\>c://app/rcs/ci.exe -x,v -l -m"none" -t-none -w"guest" c:/web/data/twiki_beta/data/Test/TestTopic1.txt
c:/web/data/twiki_beta/data/Test/TestTopic1.txt,v  <--  c:/web/data/twiki_beta/data/Test/TestTopic1.txt
initial revision: 1.1
done

The last 2 lines are not generated when running via apache.

-- HansDonner - 05 Aug 2001

Don't know what did the trick, but it seems to be working now. Apache runs under the system account and logname is now set to SYSTEM. Tried that before, but then it didn't work...

-- HansDonner - 11 Aug 2001

I ran in the same problem as Ralf and Hans. Except that I can create a new topic without problem. The RCS file is created. But, each following attempt to save the topic (modified) won't update the RCS file at all. Only the working file is changing along.

Tracing the CI outpout, I get the same result, I miss the Done part.

After what, if I execute exactly the same command (copied from the Debug file) at the command level. The file will check-in without problem and I get the Done part.

I'm stuck. Hans, do you now have a clue of what made it work ?

My config :

Apache is running under SYSTEM, LOGNAME=SYSTEM and the RCS file created is locked by SYSTEM.

The test has been done with the guest user.

I also have set doKeepRevIfEditLock to 0 for testing purpose.

I get the discribed behaviour with last production release AND last beta (03 Aug) on three different machines.

-- JeromeBouvattier - 21 Aug 2001

I'm getting clother. If I execute the CI command copied from the debug file from a very simple script like testenv, CI does complete and the RCS file is updated. So, I CAN get CI to work from a perl script called by Apache.

Now, I still wonder what happens in Store.pm (or anywhere else) that make CI to fail.

-- JeromeBouvattier - 21 Aug 2001

Ok. Found it. It has to do with the $ENV{'PATH'} and the way TWiki makes it safer in TWiki::Initialize.

In last beta (03 Aug 2001) the code is :

	 ...
	 # Make %ENV safer for CGI
	 if( $safeEnvPath ) {
		  $ENV{'PATH'} = $safeEnvPath;
	 }
	 delete @ENV{ qw( IFS CDPATH ENV BASH_ENV ) };
	 ...

Commenting the if solved the problem for me. It was because I left $safeEnvPath = "/bin:/usr/bin"; in TWiki.cfg. So, the solution is to either set $safeEnvPath = ""; (the PATH is preserved) or set something like $safeEnvPath = "path/to/rcsbin;path/to/perl/bin;path/to/cygwin/bin" . It worked for me.

In last production release (dec 2000), $envPath does not seem to be used, the TWiki::Initialize code is :

	 ...
	 # Make %ENV safer for CGI
	 $ENV{'PATH'} = '/bin:/usr/bin';
	 delete @ENV{ qw( IFS CDPATH ENV BASH_ENV ) };
	 ...

So setting $envPath didn't changing anything for me. I made things work by commenting the $ENV{'PATH'} = '/bin:/usr/bin'; line. I also tried to change it with $ENV{'PATH'} = $envPATH; and setting $envPATH properly, but I got a compile error in Apache's log.

[] Premature end of script headers: c:/twiki/bin/view
[] Global symbol "$envPath" requires explicit package name at wiki.pm line 126.
[] Compilation failed in require at c:\twiki\bin\view line 22.
[] BEGIN failed--compilation aborted at c:\twiki\bin\view line 22.

Should be easy to tweak for somebody "Perl aware". I'm not, so I didn't investigate further. I decided to continue with the last beta.

Now, can somebody explain to me the point around making the PATH safer ? I am new to the Linux_Apache_Perl_Rcs thing.

-- JeromeBouvattier - 22 Aug 2001

I still don't quite know what made my configuration work... But I believe it has something to do with the path, either the one I set in the Windows config or by the ine in twiki.cfg.

Glad to see it finally worked out for you Jerome.

-- HansDonner - 22 Aug 2001

I've also had this problem - chased it down to diff command not being available (it's required by ci ), because it was not in $safeEnvPath in TWiki.cfg

-- JohnTalintyre - 24 Aug 2001

I am running the most current beta(8/25/2001) and this is what I get every time I try to save a page:

D:/Web/rcsbin/rcs -x,v -q -u D:/Web/btwiki/data/main/WebHome.txt 2>&1 1>NUL Access is denied.

If I copy and paste that into a command window on the server it works just fine... Of course if you take the >NUL off it gives you an error about a file "1" doesn't exist, and if you take the >&1 off you get an error about a file "2" doesn't exist... This must be something special on *nix because on Windows2000 you can't specify more than one place to direct stdout... (it takes the last one) That doesn't seem to be the problem because it works even with both of them there. So I just need to figure out why save.pl can't run the rcs command... Any ideas?

I even got the DIFF portion to work, but to do that I had to give the IUSR permission to add/delete files in the TEMP directory... I would really like to be able to specify a different temp directory than the system one.

-- MichaelCodanti - 26 Aug 2001

Jerome, the idea of setting the PATH to a safe value is to prevent a user from specifying an arbitrary path and thus causing the wrong command to execute (e.g. defining a trojan horse version of 'rcs' that erases key files). Do a Google search for 'perl CGI secure programming' to find more.

Michael, the '2>&1' stuff is Unix specific, and should be removed for Windows. See TWikiOnWindows for more help in this area. IIS is a lot harder to set up than Apache, it seems.

-- RichardDonkin - 02 Sep 2001

Change all of the commands from looking like: D:/Web/rcsbin/rcs -x,v -q -u D:/Web/btwiki/data/main/WebHome.txt 2>&1 1>NUL

to looking like: D:/Web/rcsbin/rcs -x,v -q -u D:/Web/btwiki/data/main/WebHome.txt >NUL

After I made that change to store.pm, I can now save changes without error, but they are not getting checked in. What is weird is that sometimes the rev number increases, and then if I change it again it will sometimes go back down... But the ,v file isn't getting updated.

The IIS part was a breeze, I just can't get the RCS check-in stuff to work correctly. The diff part is working, so it isn't that it can't run commands or create temporary files.

-- MichaelCodanti - 04 Sep 2001

After some more research I see I really am getting a "Access is denied." error message for each rcs command issued.. I can't figure out what access is being denied too... I have given EVERYONE access to the rcsbin, and the entire twiki directory... What else could it be?

-- MichaelCodanti - 05 Sep 2001

SupportStatus:

AnsweredQuestions