估计 KDE 用户碰到这个问题的概率比较高。这个问题的起因不明，症状是要删除文件时出现
The trash has reached its maximum size! Cleanup the trash manually.
检查垃圾箱里没有东西，却无法删除文件进垃圾箱。直接删除操作不受影响。
问题的直接原因是 Trash 的 metadata 有误，解决办法是把 $HOME/.local/share/Trash 直接删掉，然后执行一下 Empty Trash 操作（其实是让 Trash 重建 metadata），以后就正常了。
今天又长知识了。
首先，最简单的，更正了长久以来的想当然，php 下 explode(‘,’, ”) != array()，而是得到长度为 1 的数组，key 是数值 0，value 是空字符串。天哪，我有多少个程序是基于 explode(‘,’, ”) == array() 写下去的，这下影响大了，得好好查一查。
其次，发现一个不晓得是 sshfs 的 bug 还是 gedit 的 bug。复制错误的过程是：用 Nautilus 或 Dolphin 打开 sshfs 挂载的目录，右击创建一个新文件。文件创建是成功的，属性是 774，用 gedit 打开它却无法保存，提示是没有写权限；但用 kwrite 编辑保存一切正常；用 gedit 再编辑 kwrite 编辑过的文件又能保存。或者，在右击创建一个新文件后，执行一次 chmod 774 filename，也能用 gedit 编辑保存了。
再次，发现在 IE6 下，用 javascript 增大元素的尺寸（比如 jQuery widget 化，增加 border，增加 padding，等），会增大父元素的尺寸。哪怕父元素已用 css 静态赋以宽度值，宽度也会被改变，这是某些精心布局在标准浏览器下很好看，到了 IE6 就面目全非的一大原因。万恶的 IE6 啊，当然从另一方面，说明精心布局仍不够“精心”。为 IE6 布局好比极限运动，挑战好心情的极限；如果看到下属多花一倍时间 fix for IE6，挑战的也是老板的心理极限。
然后，发现 jQuery gallery 里有两个 themes (Humanity, Vader) 的参数不太正常，多了 tr 参数，不知道怎么多出来的，删了似乎没影响。
最后，如果父元素包含所有的子元素都是 float:left 或 float right 的话，不做特殊操作，父元素是没有高度的。父元素的后续元素用一个 clear:both 就能站到该站的位置，但如要为父元素本身画一个边框就稍有难度。最早我用的办法是在这个元素所有的子元素之后增加一个隐形的<div style=”height:0; clear:both;”></div>，但这个硬生生加进去的元素改变了 DOM 结构，破坏了语义，不够 SEO。在 Magento 里学到了另一个方法 :after { clear:both; }，如 .clearer 的示例，但要为低版本的 IE 专门写 clear after fix。我维护一份自己的 style.css，override Magento 原版的 style.css。我觉得这个任务就很“繁重”，如果再来一份自己的 style-ie.css，override Magento 原版的 style-ie.css，就为 clear after fix？总觉得小题大作。今天发现一个 clear after all floating children 的 neat solution，就是在父元素上设定 style=”overflow:auto; zoom:1″。overflow 让父元素调整到应有的高度，zoom 也是必须的，否则 IE6…，唉！
最后的最后，发现 z-index 值在 IE6 下被重置的简单通用的 fix。这个问题的来源是若干个 position 后的元素，给它们设定 z-index，IE6 下根本不按设定值 layout，而且还摸不到规律。比如下拉菜单，有时被其他东西给压住。fix 是赋予下拉菜单 z-index 时，赋予父元素（整个菜单）更高的 z-index。