However, thread view has a potential downside: it you have several active threads going with several messages each, new messages can sometimes appear on the second page of the incoming mail screens, instead of the first page.

That’s not a problem if you’re expecting it. However, since we introduced the new Webmail system, we’ve had several complaints from customers who accidentally clicked “Switch to Thread View” without realizing what it does, then thought some of their incoming mail was missing because they aren’t used to looking for new mail on other pages. Since thread view is “remembered” even after you logout and login again, this caused some people a great deal of heartache.

From our logs, we’ve found that very few people actually use thread view. Because it seems to cause frequent problems and few people use it, we’ve made it an optional feature instead of being always enabled.

If (like most people) you don’t use thread view, you don’t need to do anything. If do you want to use thread view, it’s still available: just click “Preferences”, then click “Display Preferences”, then change “Show ‘Thread View’ Link” to “Yes”.

Table upgrade required. Please do "REPAIR TABLE `users`" to fix it!

Hmm. Well, that error message seems odd, but what the heck. After making sure there’s a current backup, let’s give it a shot:

mysql> REPAIR TABLE users;

+---------------------+--------+----------+-----------------------------+
| Table               | Op     | Msg_type | Msg_text                    |
+---------------------+--------+----------+-----------------------------+
| database.users      | repair | status   | Table is already up to date |
+---------------------+--------+----------+-----------------------------+

And yet, CHECK TABLE still says there’s a problem:

mysql> CHECK TABLE users;

+---------------------+-------+----------+-------------------------------------+
| Table               | Op    | Msg_type | Msg_text                            |
+---------------------+-------+----------+-------------------------------------+
| database.users      | check | error    | Table upgrade required. Please do   |
|                     |       |          |  "REPAIR TABLE `users`" to fix it!  |
+---------------------+-------+----------+-------------------------------------+

Hmmm. We tried every reasonable combination of REPAIR TABLE and myisamchk options we could think of, but nothing helped. Then we tried unreasonable options, including the frightening REPAIR TABLE table USE_FRM option. In our experience USE_FRM usually ends up doing the same thing as DELETE FROM table, and this time was no exception. (And that’s why you make a backup first.)

Well, let’s take a look at the table status (with the uninteresting bits removed):

mysql> show table status;

+-------+--------+---------+-----+---------------------+
| Name  | Engine | Version | ... | Create_time         |
+-------+--------+---------+-----+---------------------+
| good  | MyISAM |      10 | ... | 2007-06-08 09:44:01 |
| users | MyISAM |       7 | ... | 2005-03-15 12:03:11 |
+-------+--------+---------+-----+---------------------+

Sure enough, the bad “users” table is a different version than a good table that doesn’t have this problem. And the bad table was created when we were still using MySQL 4.1.x. This table should have been changed when we upgraded to MySQL 5, and it should be possible to fix now. Why on earth won’t REPAIR TABLE fix it?

We puzzled over this for some time, and eventually just decided to reload it from a dump. But here’s the strange thing: it wouldn’t reload from the dump, either!

ERROR 1060 (42S21) at line 20: Duplicate column name 'user_id'

What the heck? So we looked closely at the dump file, and it somehow contains this line:

PRIMARY KEY (user_id,user_id)

MySQL thinks this table has a composite (two-column) primary key, but on the same column twice, which doesn’t make any sense. So we fix the dump to look like this:

PRIMARY KEY (user_id)

And everything works perfectly when the table is reloaded.

So if CHECK TABLE tells you a table upgrade is required, but REPAIR TABLE won’t fix it, check whether you can actually reload a dump of that table. You might find something unusual and easily fixable in the dump.

PHP gives programmers a way to accept an uploaded file, store it in a temporary directory, then move it to a specific location using the move_uploaded_file() command. That’s all good — but what file permissions would you expect the resulting file to get? Most PHP documentation says that temporary files created by PHP will not be world-readable, so they’ll look like this:

0600 (-rw-------)

That’s good security. It makes sure the files can’t be accessed by Web site visitors, for example, unless the programmer takes additional steps to make that happen.

On many servers, mode 0600 is exactly what you get after using move_uploaded_file(). However, if the initial temporary directory used by PHP is on a different “file system” than the final destination, move_uploaded_file() makes a copy of the file instead of moving it. And when it makes a copy, it sets the permissions of the copy to something very different:

0644 (-rw-r--r--)

Yikes! And since you have no real control over whether there’s going to be more than one file system involved (it’s effectively random from the script author’s point of view), this means you have no idea whether an uploaded file is going to be world-readable after using move_uploaded_file(). If you want to make sure it is — or isn’t! — you have to set that yourself, using something like chmod:

chmod ($filename, 0600);

Or:

chmod ($filename, 0644);

There probably aren’t many widely-used scripts that rely on the default permissions of uploaded files (otherwise the scripts would fail on some servers and work on others, and someone would notice and fix it). So this shouldn’t be a problem, right?

Well, until recently, most of our servers had their “temporary directory” on a different file system (it was actually a “tmpfs”). This caused a problem, though: sometimes when a server hadn’t been restarted for several months, the smaller temporary directory would start to fill up (the directories only get cleaned out when a server is restarted). This made us nervous: what if a temporary directory filled up and ran out of space? So we recently decided to stop putting the temporary directory on a separate file system, setting it to use the standard disk file system after the scheduled restart last Saturday night. It shouldn’t really matter where it is, so we didn’t even bother mentioning it.

But this afternoon, a couple of customers contacted us to let us know their PHP file upload scripts had stopped working. Not being familiar with arcane details of how PHP handles uploaded temporary files, we were extremely puzzled… until a perusal of the PHP source code revealed the trouble.

Now, what we originally told the customers who had this trouble still stands: regardless of the cause, everyone’s scripts should explicitly set the mode of any uploaded files if it matters. That’s the only way to guarantee your script works properly on any server.

However, we value consistency a great deal. You should be able to rely on your scripts continuing to work if it’s possible for us to make that happen. So we’ve “patched” our versions of PHP (both PHP 4 and PHP 5) to always make move_uploaded_file() act as if the file was copied (giving mode 0644). This should “fix” any scripts that were broken by this change, even if you can’t actually fix the scripts for some reason.

I should mention that this “solution” is still too random for our taste. There’s no guarantee that this behavior is compatible with what you’d get if you tried another company’s PHP, for example. What would be better is for PHP itself to make sure the mode is always the same, and for that to be fully documented so PHP users could expect the same behavior on all servers. We’ve opened a PHP bug suggesting that. If the PHP folks ever see fit to make that change, we’ll make sure our versions of PHP do what the PHP documentation says, even if it means making our servers start using mode 0600. So again: if the mode matters to your script, make sure your script sets the mode itself to avoid problems.

Followup: the PHP developers changed how PHP works in response to our bug report, forcing PHP to use mode 0644 for files created with move_uploaded_file().

After doing a bit of diagnostics, it turned out that the problem was that her computer had selected a neighbor’s wireless network after she rebooted. This different network blocked the necessary e-mail ports, so she couldn’t do e-mail. None of this was obvious until we started examining her IP address. She solved the problem by plugging her computer into a wired Ethernet port on her router, rather than using the wireless connection. When she did this, she got a new IP address which belonged to a completely different network, and suddenly she could do e-mail again!

So if you are having intermittent wireless network problems, be sure to check which wireless network your computer is connecting to. Choosing the wrong network can cause problems for e-mail and (potentially) for other services too.

We offer a web page which displays your IP address and host name. The final part of your host name is the network which are you using to connect to the Internet. For example, if your host name is c-71-205-218-196.hsd1.ca.comcast.net, then you are connecting to the Internet via Comcast.