Bug: Save Does Not Save
On our TWiki at work, periodically (actually quite frequently) when you edit a topic and go through the preview/save cycle, you will find that the topic was not saved after all.
Symptoms like this have been discussed as, for example,
ViewAfterSaveCachesOldPage,
ViewAfterSaveLosesText,
BrowserAndProxyCacheControl.
However, I have observed that whenever this symptom occurs, the following messages appear in the error log for the web server:
[Sun Aug 4 13:15:02 2002] save: Can't create file /proj/twiki/data/Main/WebPreferences.txt
[Sun Aug 4 13:15:02 2002] save: print() on closed filehandle TWiki::Store::FILE at ../lib/TWiki/Store.pm line 1169.
These error messages lead me to believe that this is not cache related? By the way, I never experience these symptoms on my TWiki on my laptop.
Test case
None. The problem is intermittent.
Environment
TWiki version: |
Athens (Dec 2001) |
TWiki plugins: |
many |
Server OS: |
Solaris 8 |
Web server: |
Apache |
Perl version: |
|
Client OS: |
Windows 2K, Solaris 8 |
Web Browser: |
IE, Netscape |
--
ThomasWeigert - 14 Aug 2002
Follow up
This is reminiscent of a problem someone had, can't remember the topic name though but a search in Codev and Support may turn it up (and try
Google:twiki+save+closed+filehandle - turns up some relevant pages).
It would be worth putting in some
writeDebug
calls with extra error checking around the code that creates the filehandle used at the line mentioned. See
TWikiDebugging for some pointers on this.
BTW, the above Google search also links directly to URLs that run the
statistics
script - this is clearly not a good thing, as the web crawler is actually causing the script to run, just by following a link! The solution is to include only
view
and a few other scripts in
robots.txt
, see
Google:robots+txt for details.
--
RichardDonkin - 15 Aug 2002
I run into the same problem a few times:
happenened to be wrong file permissions,
coming from
- uploading stuff, necessarily a different uid than httpd
- editing directly (don't tell anybody ;- )
Depending on what was wrong,
[Back] and [Save] again would fix it.
HTH
PeterKlausner - 15 Aug 2002
Thanks to the pointers above. This topic turns out to be a duplicate of
ChangesNotSaved, and the solution is as described above.
Here is the interesting twist on this....
- When a topic
.txt
file is not writeable for for the user as which the CGI script is running, at the first save attempt the file is made writeable to that user, but the save fails and the original file is shown.
- On the second save attempt the save succeeds, as the file is now writeable to the CGI script.
The question I have, without studying the code... if anybody went through the effort of changing the file permissions on the save attempt, why would we not just save the file for real?
--
ThomasWeigert - 16 Aug 2002
Fix record