Question

I sometimes (1 in 3 tries maybe) get the following error when I try to edit a page. It almost always seems to occur with attachments. After receiving the error, the changes are correctly saved, but the revision number is set back to 1.1, apparently loosing all earlier revisions.

Any help is greatly appreciated.

Thanks, Steve

-- StevenHammond - 28 Jan 2002

The information on the revision number may be inaccurate. It clearly doesn't increment the number correctly, but I can't reproduce the setting of the number back to 1.1.

Thanks, Steve

-- StevenHammond - 29 Jan 2002

Topic save error

During save of file WorldMaps an error was found by the version control system. Please notify your TWiki administrator.

/usr/local/bin/ci -l -q -mnone -t-none -d'28 Jan 2002 - 22:27' -w'shammond' /home/httpd/twiki/data/Daggers/WorldMaps.txt 2>&1 1>/dev/null

ci: unknown date/time: 28 Jan 2002 - 22:27

ci aborted

Go back in your browser and save your changes locally.

I've got a Login name now, so I updated that. The issue seems to be related to an edit->preview->save->edit cycle in a short time period. Is this possible related to the RefreshEditPage bug? We don't seem to be having an issue with losing data in the edit page.

-- StevenHammond - 04 Feb 2002

• TWiki version: 01 December 2001
• Web server: Apache
• Server OS: Linux
• Web browser: Netscape 4.0
• Client OS: Windows ME, Windows NT 4.0

-- TWikiGuest - 28 Jan 2002

Answer

Not sure what is happening here, but I doubt it's related to RefreshEditPage, as that's to do with BrowserAndProxyCacheControl.

I just tried the command line ci -l -q -mnone -t-none -d'28 Jan 2002 - 22:27' -w'shammond' foo on Red Hat Linux 6.2, using RCS 5.7, and I got the same error - on removing the '-' in the date format, i.e. ci -l -q -mnone -t-none -d'28 Jan 2002 22:27' -w'shammond' foo, I didn't get the error message. So I suspect this may be relatively easy to fix - just find where the save script or TWiki.pm is creating this command string, then find the date string, then take out the '-'. Presumably this code path is only taken occasionally; I've never seen this on our local TWiki or TWiki.org.

I just had a look at the code (for March 2001 beta, the release you are using may differ), it's in TWiki/Store.pm - the line to look at is just after the use of $revCiDateCmd, where there is a s/%DATE%/..../ command - so all you need to do is to do is add a line after this one, something like $tmpl ~= s/ - / /; to take out the '-' (check the actual variable, my VPN session just crashed so I can't see the code right now!) However, this is untested, possibly wrong, and a quick hack - it is really best to delve into the Store.pm code to find out why it's generating an invalid date format - I think the date comes from rlog, i.e. $revInfoCmd, but I don't have time to look into this further. Judicious use of the writeDebug call should help.

You might want to check you are using RCS 5.7 and Perl 5.005_03 or higher, as well.

-- RichardDonkin - 05 Feb 2002

Thanks for the info, I'll try looking into this. I don't know perl, yet, so I'm sure it'll be a challenge. Perl shouldn't be a problem, I've got several other scripting languages under my belt, but is there a primer on the TWiki code, conventions, architecture, etc.?

The problem seems to be related to the lock timeout and possibly checking things in, within the two minute increment I found in Store.pm (I'm not sure about this last part, though). Probably, not may people are trying to save within two minutes of the last checkin, but we seem to do a lot of it.

I set the lock timout to 0 and the problem went away.

-- StevenHammond - 06 Feb 2002

I don't think there is a primer on TWiki architecture etc, you will just have to read the code For Perl info, see http://www.perl.com and Wiki:PerlLanguage - also have a look for CGI.pm manual pages, as that's how TWiki does the CGI stuff.

Interesting about the lock timeout and rapid saving after last checkin - the bug might well be in every TWiki installation but only brought out by your usage patterns. I can't see how putting '-' in the date string would ever work!

-- RichardDonkin - 06 Feb 2002

I just experienced the same thing. I tried solving it by setting the lock time to zero (Line 1001 on my copy of Store.pm.) but that didn't work. I finally traced the hypen down to line 545 of TWiki.pm in formatGmTime. I just took the hyphen out of the sprintf. I'll see if it breaks anything else, but it seems to be working now.

• rcs-5.7-13
• perl-5.6.0-9

-- GeraldSkerbitz - 20 Apr 2002

Are you using the Dec 2001 code? I think the hyphen is on line 559, last line of formatGmTime in this code. I spent some time looking at the code but it's not clear where this value comes from - perhaps formatGmTime is called without the required "rcs" parameter at some part, resulting in the '-' being included in the date format generated by this routine.

Changing this line in formatGmTime will change the default date used by %DATE%, so it would be good to fix this properly.

-- RichardDonkin - 20 Apr 2002

Yup. You're absolutely right. I'll dig to see what's calling it without rcs. Thanks.

-- GeraldSkerbitz - 20 Apr 2002