Question

• TWiki version: Dec2001
• Perl version: Cygwin Perl 5.6.1,
• Web server: IIS 5.0
• Server OS: Win 2K
• Web browser:
• Client OS:

I get all the symptoms of the Save Not Saving files. I have looked into the permissions and I find that the files are being created owned by the User who created the file rather than the WebServer itself. This means that the files can not be written back and hense the syptoms of file being edited but not saved.

I believe this is exclusively an IIS problems

-- MartinRoberts - 06 Dec 2002

Answer

I don't know anything about IIS really, but have a look at CookbookWindowsIISSetup (found with Google:twiki+iis+cookbook). Specifying a lot more detail, e.g. your IIS, Perl and other versions and supplying info as per the SupportGuidelines, e.g. the actual error messages, testenv output, etc, would probably be useful to whoever is able to answer this question.

I'm genuinely curious why so few people supply the information asked for in the SupportGuidelines... Is it because of the extra 5 minutes it would take to get hold of this info? Or is it because nobody wants to read the guidelines in the first place?

-- RichardDonkin - 06 Dec 2002

Firstly, Richard as a Newbie I had not realised the angst it caused by not filling in the details. The other reason is that I am not clear how this stuff seems to work. i.e. Which perl is actually running as I am not sure how windows access the various versions on this platform.

Having got that out of my system that still leaves me with the problem. Can I explicitly set the file owner and permissions from inside the Store.pm. It seems that IIS uses the windows security which seems to override what would have happened on Apache. I am only on ISS as I could not get Digest:SHA to work under Apache 1.3.7 as it failed a test in CPAN, See earlier support request.

-- MartinRoberts - 06 Dec 2002

Well, reading the SupportGuidelines makes it clear why this is useful for all parties... I assume you've now read them? They are aimed particularly at new users, who tend not to provide enough detail. If it's not clear why these guidelines useful, please comment here.

As I'm sure you will have noticed, the guidelines provide detailed instructions on checking Perl versions, and recommend using the new testenv, which is easily installed and provides a lot of detail on your setup. I have spent a lot of time enhancing testenv to help people diagnose problems on TWiki, particularly on Windows. If people aren't willing to spend 5 minutes reading the support guidelines and providing information based on the new testenv, I don't see why I should spend time answering their questions.

You have provided very little detail on what's happening, and guessing the problem is a waste of time. Talking about possible solutions by hacking Store.pm is also a waste of time since you haven't provided enough detail yet...

I have answered the Digest::SHA1 questions and provided links to binaries that can be installed on Windows, so that might be an easier approach.

-- RichardDonkin - 07 Dec 2002

Richard I am afraid that your your answer for Digest::SHA1 did not work for me as it still failed to test without giving a core when I tested it. As I am not in the position to get that working I moved to IIS.

I thought I had explained the problem. What is actually happening is that when a Topic is being created it is given the ownership of the remote user who has logged onto the Twiki, along with restricted file permissions that mean no one can change the file. When someone else tries to edit it they end up being able to go as far as the preview but then the save fails with no error message at all. The answer is simple, I neded the files created under System with the file permissions of read write for everyone. However, I do not know how to get IIS and Perl to do this by default.

I have tried unsuccessfull to set permisions from within windows, but have managed successfully within Cygwin to change the the ownership to System and the permision to 664 or 666. However, this does not rectify the problem that the next new file will be owned by the remote user and will only be readable by everyone else but not writable.

I am unable to conect today to confirm the testenv, but will check Monday. I someone could help in explaining how I can get IIS to by default create files under a general user with general read and write permissions I would be grateful.

The idea of changing Store.pm is not one I wish to go down, but it may mean I can restrospectively force the ownership and permissions correctly from within Twiki rather than relying on IIS.

Lastly Richard I very much appreciate yours and evryone elses help in getting this to work as the response to TWiki in my organisation is very very positive and without these small teething problems I hope to be able to add to the long list of successful testomonials.

-- MartinRoberts - 07 Dec 2002

Re the DigestSHA1FailsCPANTest problem - it would have been good if you commented there, as there is no need to run the 'make test' or do anything in CPAN if you download the .tar.gz file attached to InstallDigestSHA1Fails. It's quite possible the test is doing something that's not required for TWiki to work, and the file's binaries did solve this problem for ChrisWolske. This tar file includes binaries that are just un-tarred from the / directory in Cygwin, so they should work immediately. Probably a lot easier than fixing IIS - at least one person switched from IIS to Apache just to get TWiki working...

The IIS problem you are having sounds like it requires IIS-specific setup to fix - most web servers don't run CGI scripts as the remote userid. You can change file permissions perhaps, but you would probably not be able to change ownership (Windows NT/2000 only allows you to take ownership of other files, rather than give it away). Even changing permissions may be challenging since Cygwin's normal permission mode doesn't map onto Win2K - you would need to investigate Perl Win32::* modules to do this. It might be simpler to just stop IIS doing this through configuration tweaks - you would need to find someone who really knows IIS and Win2K and provide them with the details.

Given the Apache and IIS related problems outlined, I'd say it would be much, much easier to get Apache working, if only because there are many existing Apache+Windows installations of TWiki and very few IIS installations. Once you have this working you can also investigate ModPerlWindows which will greatly outperform IIS using CGI Perl.

-- RichardDonkin - 07 Dec 2002

Thanks Richard. I will try the Apache again when I get in the office. I will also follow the down load again. BTW I really appreciate your help and instructution, I will try to be more complete in my explanations in future

-- MartinRoberts - 07 Dec 2002

In the end I moved back to Apache and as RichardDonkin said the InstallDigestSHA1Failsproblem was fixed with the download on the page that I had originally failed to load correctly. So now I am up and running with a few minor Permissions problems.

Thanks Richard

-- MartinRoberts - 17 Dec 2002