Perl/CGI Permissions/Ownership Confusion

[mikedj]

I seem to be having a permissions or ownership problem with perl cgi scripts. It's been many months since I uploaded perl scripts, but my existing scripts have been executing fine all along. I made a minor change to one script tonight, uploaded it and got a "500 Internal Server Error".

I can edit existing files via FTP and they still work fine. But as soon as I upload a new file or overwrite an existing file, I get the error (I set the permissions to 755).

The reported file sizes are also different for files with the exact same perl code in them. The existing files (that still work fine) are slightly smaller (98.38KB) compared to the newly uploaded files with identical code (0.10MB).

Any thoughts?

Thanks,
Mike

[Spathiphyllum]

What FTP client are you using? Have you made a setting change in that client that masks permissions? You are uploading as ASCII/text, right?

First, I'd add:

use CGI::Carp qw(fatalsToBrowser);

near the top of the script during debugging. That could verify that it's a permissions issue as opposed to a compilation/runtime issue.

If nothing obvious resolves, then I'd try uploading with WinSCP and changing permissions using that client instead. I've had FTP clients where permissions were presumably changed but really weren't. WinSCP to the rescue.

If WinSCP reports that all is executable, and a 500 error continues, then it's probably a server issue and you'll need to check the server config files for some quirk. That seems unlikely, however, since the same local file should operate just fine when placed in a cgi-bin server directory if it had been running OK previously.

[mikedj]

I'm using CuteFTP Pro 1.0. They're up to version 8.0 now, but I've never bothered to upgrade. It's been working fine for me for many years.

I tried your suggestions and learned some new things. I've narrowed it down to an ASCII transfer type issue.

I started with a fresh, simple test script. I tried changing permissions using Putty, WinSCP and CuteFTP. All seemed to make the changes and report the same results, but the error continued. I then uploaded the file using WinSCP and got it to work.

I reapplied my Global Setting in CuteFTP to make sure it was transferring cgi extensioned files in ASCII mode. Still no joy. I then forced all transfers to that host to be ASCII. It worked. I then changed it back to Global settings, which uses the extension list to decide which files go ASCII vs. binary. I transferred the file again and started getting the 500 error again.

So, it seems CuteFTP is not honoring its own rule. The file doesn't seem to be transferring in ASCII mode, even though the settings dictate it. Something has apparently changed since I've been using CuteFTP in this way for many years with no problems. I'll have to keep digging to find out exactly what is happening, but I thank you for the suggestions. It has helped get me going again, albeit limping at the moment.

Thanks,
Mike

[mikedj]

Ok, so on the File menu, there's this entry called Transfer Type... When it's set to Binary instead of Auto, guess what happens

Of course, I have no idea how or when I changed it. Probably one of those late night, bleary eyed programming sessions. So the moral is, there are several settings in CuteFTP that can affect whether a file is transferred in binary or ASCII.

Again, thanks for the help.

Mike

[Spathiphyllum]

You're welcome.

I don't use CuteFTP but I've seen similar stuff happen in several other clients. Whether a bug, feature, or other, developers need several apps that perform the same duties to escape the very issues you experienced. Glad you were able to track things down.