NineChime forum

D= so you only get it every once in a while? do you ever do anything to try to fix it? if not then maybe it is a server issue like i suspected. though if it was one, i would have expected the issue to have been worked out by now >.> unless my host is being really slow with fixing stuff.

i also noticed that when i truncate the oekakidta table, the problem gets fixed, but when i re-add the rows to the table, the problem comes back.

Last edited by sfox8 (01-06-2007 15:54:09)

i also noticed that when i truncate the oekakidta table, the problem gets fixed, but when i re-add the rows to the table, the problem comes back.

Could you ellaborate on this?  What rows are you adding or removing?

When you add rows, are you setting the default values correctly?

I've never tried to fix it...xP Mine is probably problems with my host...-is using funpic- Other people on other oekakis hosted by funpic have the same problem.

Funpic uses a security policy where if certain words are used, the server will ignore submissions, as if they were never sent at all.  This is for anti-spam purposes, so even common words like "work" and "job" will make the server go ballistic.

I no longer recommend Funpic as a host for oekaki.  This kind of spam paranoia is unacceptable.

Oh, so by truncate, you mean removing pictures in the table, not field names.  OK, that makes more sense.

The only thing I can think of is that the picture counter got messed up.  Go into the dianostics page ("infotest.php"), and make sure the "Current picture number" is higher than the total number of pictures allowed on the board.  If not, the number needs to be reset to something higher that won't conflict with any existing picture numbers.

Also, be aware that when you remove rows from "oekakidta", there will be orphaned comments in "oekakicmt".  Don't mess around too much with the pictures database, or tons of garbage will build up.

Computers on the Internet are much more paranoid about security than home computers.  They have to be, of course.  Folders can become locked for a variety of reasons, but it usually has to do with your Group ID (GID).

If a folder is created by a script, its GID is the same as the scripting language.  If a folder is created or modified by the FTP server, a different GID is used, either the GID of the FTP server, or the GID used for your server account.  Servers like everything to be the same GID.  If the GID doesn't match up, the only way to gain access to the folder is to reduce the security level with a CHMOD.  In some cases, the server might have a watchdog security program that will lock folders if suspicious things happen, like, moving massive numbers of files.

You may have no choice but to CHMOD the folder every time you copy stuff.  Also be aware that files moved into a folder also have a GID, so you might have to CHMOD every file you copy over, otherwise the board will not be able to overwrite old files, and therefore new files cannot be written.

That's UNIX.

If this problem is inconsistent, it should be a filesystem issue, and not a database issue.  But, you said the board wasn't inserting pictures into the database.  That's kind of strange.

OK, so this error message is returned by the uploader, right (not the oekaki applets)?  The uploader is what returns the phrase, "Could not insert picture into database".

In functions.php, look for the comment "// Upload picture".  Scroll down and look for this code:

if (!$result) {
    error_log ('Upload failed: Picture='.$p_prefix.$resno.'.'.$slot['ptype'].'; Owner='.$OekakiU.'; DB: '.mysql_error());
    report_err('Could not insert picture into database.');
}

Now, FunPic doesn't allow access to the PHP error log, so we'll have to make a substitution so we can get the exact error from the database.  Replace that code with this and retest:

if (!$result) {
    report_err('Fail-DB: '.mysql_error());
    // report_err('Could not insert picture into database.');
}

I should probably write a wrapper for the error_log() function.  PHP's error reporting is pretty much useless unless you actually OWN the server, which, of course, most people don't.

Well, I had that too but I hit the button print screen and it sent.

That's definately a duplicate PIC_ID.

I know you're using a mod of the board and can't easily update code.  Which version of Wacintaki are you using?  I think a simple adjustment to "paintsave.php" and a piccount reset will fix this, but I have to know the exact verion.

Basicly, kill_post_files() and kill_picture_slot() are called to replace existing posts, but you have to call the right one.  Updated boards might have an issue with these functions if the SQL5 update doesn't work as expected.

For now, let's just try to reset the counter.  Wacintaki counts up infinitely so picture slots are no longer re-used.  If the board was updated after the counter was rolled-back in a previous version, sometimes that can cause problems with pictures disappearing. 

Counter reset

If you have this problem again, it's possible the MySQL5 database update may not have updated everything properly.  I have another stand-alone script to fix that, too.