Is that why the main graphic and tip on www.photodesk.iconbar.com aren't working? What should I change? chmod is a bit of a mystery to me.... (They both run the random cgi script.)

Chris

That looks like a file permissions problem. Hopefully John Duffell will realise TIB's back sometime soon, check his site over and fix it - if not, then you'll have to shout at him a bit to wake him up

That looks like a file permissions problem. Hopefully John Duffell will realise TIB's back sometime soon, check his site over and fix it - if not, then you'll have to shout at him a bit to wake him up

That is mine, not John's.

And if I try to chmod those files I get:

SITE chmod 777 webcount.dat
550 proflawn.dat: Operation not permitted.

So hopefully rich can fix it

Many sites seem to have had their file permissions messed up, stopping PHP scripts which try writing to files from working. Is there a quick fix for this, or is the only way round it to FTP in and chmod all the files by hand?

Also it looks like some or all of the affected files have had their unix user ID changed to a different value, meaning the file must be downloaded, deleted from the server and then uploaded again in order to be able to chmod it from FTP

Cheers,
Rich.

I need to know exact domains and files to change; I can't just open everything up to everyone!

/stats/ pages don't appear to be updating (or atleast the one on http://banners.iconbar.com/ isn't)

Cheers,
Rich.

At the moment I'm battling with my own PSU problems - computer keeps dieing because we're overloading it a bit

Cheers,
Rich.

5. The riscos.iswe.net and quote-egnufeb-quote-greaterthan-colon-hash-comma-underscore-at.info stats seem to have lost their MIME type too

Cheers,
Rich.

5. The riscos.iswe.net and quote-egnufeb-quote-greaterthan-colon-hash-comma-underscore-at.info stats seem to have lost their MIME type too

Not sure if it's what you mean, but stats on one of my domains didn't work because the manner in which SSI is added to a domain has changed between apache 1.3 and 2.0. To be fair both methods were listed in the main config file. But f*ck fair, because neither were compatible with the actual method in use on the old server, meaning there's at least three methods of doing the same thing. It's enough to send you screaming to IIS

Fatal error: Allowed memory size of 8388608 bytes exhausted at (null):0 (tried to allocate 6400 bytes) in /virtual/www.banners.iconbar.com/webpages/sober/riscpc/index.html on line 48

Fatal error: Allowed memory size of 8388608 bytes exhausted at (null):0 (tried to allocate 6400 bytes) in /virtual/www.banners.iconbar.com/webpages/sober/riscpc/index.html on line 48

Why would you want to take photos of your hard disc?

This used to work



Fatal error: Allowed memory size of 8388608 bytes exhausted at (null):0 (tried to allocate 6400 bytes) in /virtual/www.banners.iconbar.com/webpages/sober/riscpc/index.html on line 48

Cheers,
Rich.

This used to work



Fatal error: Allowed memory size of 8388608 bytes exhausted at (null):0 (tried to allocate 6400 bytes) in /virtual/www.banners.iconbar.com/webpages/sober/riscpc/index.html on line 48

No idea. It should be pointed out that we're using a completely different version of apache and PHP, so it's entirely possible that it's the code. The images certainly seem to be there.

Of course, I pre-thumbnail all of mine, which works whatever version of PHP is installed ;^)

[edit]
OK, the error returned by the bad thumbnail image is...
Fatal error: Allowed memory size of 8388608 bytes exhausted at (null):0 (tried to allocate 6400 bytes) in <your file> on line 48
...which is...
$im = ImageCreateFromJPEG($thumbnail);

The same script works fine if the size of the image source file (i.e $thumbnail) is smaller.

Cheers,
Rich.

1. My forum account at Acorn Arcade has vanished
3. Several forum accounts have vanished from Coder's Cauldron

Hmm. When I log into my mail using Pine, I get the warning:

Mailbox vulnerable: directory /var/spool/mail must have 1777 protection

Cheers,
Rich.

• Why does Pine require that the mail spool directory have 1777 protections?
  Pine was designed to run without special privileges. This means that in order to create a lockfile in the spool directory, it is necessary to have the spool directory permissions be world-writable.
• Can't you create the lockfile somewhere else?
  No. The lockfile in question must be in the mail spool directory, because that's where the mail delivery program expects to find it, and the purpose of the file is to coordinate access between the mail client (Pine) and the mail delivery program.
• Isn't having the spool directory world-writable a big security risk?
  No. Remember that the individual mail files in the spool directory are NOT world-writable, only the containing directory. Setting the "sticky bit" -- indicated by the "1" before the "777" mode -- means that only the owner of the file (or root) can delete files in the directory. So the only bad behavior that is invited by the 1777 mode is that anyone could create a random file in the spool directory. If the spool directory is under quota control along with home directories, there is little incentive for anyone to do this, and even without quotas a periodic scan for non-mail files usually takes care of the problem.