沙漠之周的Blog

修改完/etc/my.cnf的配置一直没有重启，今天重启了一下，看似一切正常，但是却没法访问原有的数据表，出现类似的提示：
Incorrect information in file: './DATABASE_NAME/TABLE_NAME.frm'

仔细查看mysql的错误日志文件，发现提示ib_logfile0文件大小设置不正确：

InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 268435456 bytes!

下面即时具体受影响的数据表信息。

显然mysql启动时会对比ib_logfileN和配置里设置的文件大小，可见是我更改innodb_log相关的配置导致的：
> innodb_log_file_size = 256M
> innodb_log_files_in_group = 3
< innodb_log_file_size = 5M
< innodb_log_files_in_group = 2


改回以前配置就没有问题了。

今天犯了一个很低级的错误，通过命令行恢复一个mysqldump出来的很大的文件时，由于没有没有将它放到后台进行，运行几个小时之后突然由于超时而中断与远程服务器的连接了。幸好可以通过SQL语句导出导入部分记录的数据：

导出：

SELECT * FROM park_log WHERE pl_id > 51025594 INTO OUTFILE '/tmp/apps_park_log_51025594.txt';

导入：

 LOAD DATA INFILE '/data1/apps_park_log/xB' INTO TABLE park_log;

yejr曾经测试比较，LOAD DATA比导入SQL文件快，但由于LOAD DATA必须所有操作进行完之后才向数据库里写记录，所以有时候往往会感觉LOAD DATA比较慢。我刚操作一个数千万行的文件时，还以为程序没有工作而手动中止了。真是一个活生生的例子。

工作遇到了一个奇怪的现象：windows下访问某个IIS服务器没有问题，有的Linux也可以正常访问，但有的Linux访问时，服务器回应十分迟缓。

后来在bbs里有人让我参考kernel相关的一篇文章，原来自从内核2.6.17版本后TCP window scaling的变动导致无法访问某些路由器。

我进行如下设置，解决了问题：
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

有些编辑器，比如M$ Windows的记事本，在创建UTF8编码文件时会在头部添加一个不可见字符。这个字符可以通过vim查看到，而且如果是一个php文件，php4、php5在解析时均会有输出。

原来这个被称作BOM(Byte Order Mark)的不可见字符，是Unicode用来标识内部编码的排列方式的，在UTF-16、UTF-32编码里它是必需的，而在UTF-8里是可选的。因此，才会出现有的编辑器在文件头部添加添加BOM、而有的语法解析器又不作处理的的混乱情况。

根据w3c里FAQ的建议，解决方法就是，删无赦！

btw, 刚才无意中发现，PHP 5.2.5的命令行下去除了BOM的显示，而 PHP 5.2.6确又显示出来了。

以前曾用过Pure-FTPd提供的ftp服务，作为ftp的服务器端，其类似linux下useradd/usermod/passwd工具的用户管理方式，令人印象深刻。最近正好需要配置一台ftp服务器，当然首选这款有良好安全性口碑的Pure-FTPd。

基本需求是这样的：
虚拟用户 - 也就是说提供的ftp用户在系统里并不存在
权限 - 每个用户对自己目录拥有读写权限，但不允许访问其他目录
虚拟目录 - 每个用户目录下面需要添加一个只读的公有目录

以下为配置过程：
1. 安装
当前最新版本为1.0.21，可从官方网站下载。

刚才无意中通过浏览器看到了wordpress配置文件里的信息了，现在想想仍心有余悸。

如果你像我一样，将vim作为首选编辑器；如果你也像我一样，有时候需要远程修改文件。那么，请注意了，通过vim远程修改文件，可能会产生~结尾的备份文件，由于服务器一般都无法解释~后缀文件，这将把代码泄露给客户端。如果巧好是某个配置文件，后果更是不堪设想。

解决方法：
1. 通过设置nobackup和nowritebackup参数，取消vim的自动保存功能
2. 让web服务器解释~后缀文件

Google的服务一向以稳定而著称，但我却看到了gmail在打盹。

刚才打开浏览器，通过Gmail Notifier 插件登录gmail。其实我以前保存了密码，但它却提示我验证失败，于是我输入密码重新登录。一串提示性的文字一闪而过，大意是说我的网速慢之类的。此后本来应该显示熟悉的gmail首页，但是紧接着却出现了白底黑字的javascript代码，还以为是我搞错了，重新打开一个标签登录，依然如此。

最近碰到一件奇怪的事情，使用gmail收到来自雅虎信箱(yahoo.com.cn)回复的邮件时，标题总是或多或少出现乱码。

于是我注册一个雅虎信箱，分别给gmail和公司邮箱(使用客户端sylpheed收信)发送邮件。如果标题超过20个中文，收到的邮件标题确实会显示部分乱码。有意思的是两者显示乱码的方式还不一样：gmail将第20个中文后的字符显示为乱码；sylpheed则将第21、22个中文显示为乱码。

smtp协议似乎并没有对邮件标题长度做限制，不知雅虎信箱为何对标题的第40个字符这么敏感。

btw，在网上搜了一下，发现雅虎邮箱在年初也曾出现过乱码。

由于使用了退格(backspace)、覆盖(substitute)、垂直方向(vertical tab)的tab等控制字符，很难直接读到mplayer/ffmpeg运行时的信息。其实按字符读取并过滤其中的控制字符，便可以还原其输出信息的“真面目“了。以下是在php中的实现：

旧mysql版本为4.0.22，新数据库版本为5.0.37，旧库中使用的字符集为utf8，phpmyadmin版本均为2.9.11，具体过程如下：
先在使用phpmyadmin从虚拟主机mysql4.0.22的数据以sql语句方式导出，然后在本地mysql5.0.37上同样使用phpmyadmin导入，发现有如下地方需要修改

old
new
备注

`type` enum('原创','转载') NOT NULL default '转载',
`type` enum('原创','转载') NOT NULL,
如果enum的值为英文，则无需修改

) TYPE=MyISAM AUTO_INCREMENT=185 ;
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=185 ;

) TYPE=HEAP MAX_ROWS=500;
) TYPE=HEAP MAX_ROWS=500;