Furry stuff, oekaki stuff, and other stuff.
You are not logged in.
I think the fix worked! I uploaded without a problem and the applets are working fine now. Thanks so much yet again. You're a life saver.
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.
I'm using 1.3.5.
Ah, I'm glad we know what the issue is now.
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.
Fail-DB: Duplicate entry '621' for key 2
That's the report I got from the uploader. But just for the record, when the uploader doesn't work, neither does the applet. It'll tell the user to take a screen and try again.
So does that error mean that it can't submit because there's already a picture in the database with the number 621 in the PIC_ID or ID_2?
Well, I had that too but I hit the button print screen and it sent.
Actually, I use DreamHost, not funpic anymore. But it seems that whenever the uploader gives the error, the applets dont submit pictures either. It'll tell me to take a screenshot of the picture.
I'll try what you just posted in the morning though, to see what it'll come up with.
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.
Ack.. it's doing it again. @-@ But this time it says it can't insert the picture into the database (which is strange, because i havent touched any oevista file or database since I started this topic). Could it really be the host that is causing the problems (can it be solved by switching hosts?) or is it something I've done on my side?
I can try CHMODding every file like you said, but I just want to verify with you that it won't cause anymore damage to the oekaki than what's already been done. xD;
It also seems to allow certain users to upload and draw with no problems at certain times, but others can't. (me included in the latter)
very strange..
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.