| written by Alex on Jan 01, 2005 11:59 |
 | |  | | ![]()  january 1, 2005: Postlīne | | | | - the members database data loss bug striked again: I've restored from last backup point, and synchronized the private messages database to avoid the problems we had last time, you may therefore find old messages on top of your PM list, marked as unread, but nevermind them, marke them read or delete them, as you prefere; consider that if they are there, it's because otherwise they would have been missing from your inbox completely.
- tonight, while I wasn't showing here, I managed to backup the existing phpBB database to save it from an eventual deletion, depending on what I may decide to do with the old forums. What's important is that with the backup, I have all I'd need to rebuild the old forums even after deleting them.
- again, about that bug: it doesn't concern the scripts, it doesn't concern Postline, it concerns "safe mode". This server runs in safe mode, and PHP scripts can be interrupted, between an instruction and the next, by a "user break", or someone pressing the stop button, closing the browser or jumping to another page in the worst possible moment: while the script was about to write something to a file, after having opened the file and truncated it to zero bytes. To solve this problem definitely, we need to avoid touching the target file directly. Postline will now write files to a temporary transfer folder, then copy them to the intended destination with a single instruction, and finally removes the temporary file with another instruction. Because of how phplib works, a single instruction cannot be interrupted, and that's were this method solves the problem. Yes, I know it sounds weird, but after all this time looking for an apparently non-existing bug, I'm quite convinced it must be so. With this behavior, file write access is obviously slower, and that's also why I didn't want to give it a try before; now, I really feel compelled to. However, considering the many optimizations done since the past PL2004, I don't think the apparent speed will be noticeably affected in our current situation. Also, this is avoided on files like the session table and the chat frame, which are written very often and which could even be lost without permanent damages. Due to Murphy's law of course we did NEVER lose one of them in place of a much more important one...
- note that because copying (first) and deleting (then) are two adjacent instructions in the script, if the script is interrupted in-between, we'll also have a way to trace the failed transfer, because the temporary file (which name is unique, dated, and won't interfere with subsequent writes to the same file) would remain in the vectors' folder.
- other than this, I've changed some things here and there, mostly making cosmetic changes and internal optimizations, and oh... switched back to lowercase on default. Small caps are now an option. In fact, your prefs cookie as it is now will need to be updated: the switch works in the opposite way as before, so those who had small caps disabled will now be the only ones who'll find them enabled. However, you only have to visit your prefs and turn that switch off... the main reason for this change of mind: small-caps are only good if seen with cleartype fonts rendering, which not all OS's have, and certainly not by default. They look tragically unreadable with standard TTF handling.
- one more thing: you'll see a code in the lower left side of the speech balloon. It's for visually validating the message against abuse of div and similar tags with "position" properties, in short: the game you were playing in The We Don't Care Thread. Postline will show an alert in place of the code if a suspicious property is used. Because a clever cheater could think about covering the WARNING too, I've made it so that the warning replaces the validation code, which itself is impossible to reproduce from within a post (it's made by Unix epoch current second, and the first octet of the viewer's IP address, go figure...). | |  | |  |
|
|
