The pack I just downloaded had 5 0 0 set on all files for max.resist. Took me a bit to figure out why it wasn't working. Just a heads up if you can't get it running upon upload to change the permissions.

The download is a zip file. Zip files do not contain information about file ownership and permissions so this problem was caused by a tight umask on your server.

Still, it's a good tip though. The php files should be readable by the user under which your webserver runs (most of the times www-user or something like that)

What are you using to zip it? Winzip? I ran into this issue once before, the unzip application in OS X has an issue with certain zip files from Windows. The odd thing though is if I unzip it from the terminal with 'unzip', the permissions are correct.

If you give me some more information on what app/version you use to zip, I can see that this gets submitted to Apple as a bug. Thanks.

I used PowerArchiver to make that zipfile, but once again, zip files do not contain *any* information regarding file permissions so it couldn't possibly be a bug in Apple's archiver. The only possible bug in Apple's archiver might be that it deviates from the default umask set by your system. I'm quite sure that if you'd report it you would get a reply that "it's working as intended".

This doesn't explain why only max.resist of all the downloads here gives me these file permissions with Bomarchivehelper (Mac OS X's unzip application, used with Safari) but not unzip (via terminal), and not Stuffit (used with Firefox). As a developer at Apple, I wanted additional detailed information so I can file a bug report... it could be already fixed, a duplicate, or any number of issues. Bomarchivehelper doesn't deviate from my systems umask, so why it is for this file... is a mystery.