最近遇到了一个bug，详细情况如下：用linq to xml写xml文件，在加载的时候代码为xDocument.Load(filePath),保存的时候为xDocument.Save(filePath)。出现的问题是在文件的最后可能会多出几个字符，可能是xml文件最后一个标签，可能会更多。
遇到这个问题，开始想是不是自己代码有错误之类的，但由于本代码不会在多进程下运行，仔细看过代码之后没有发现文件读写流没有关闭的问题等，也没有其他明显的代码错误。有次调试过程中亲眼监视了最后保存之前的xdocument内容完成正确，执行完下一句之后文件里面的内容是错的。。。
百度google了许久终于在stackoverflow上找到了一个遇到同样问题的悲催IT男。虽然他出错可能是因为他load的时候load的是一个读文件流，在写之前也没有释放，可能是由于文件流未释放导致的问题。为此我还特意反编译了ms的dll，证实了微软的大牛们还是很靠谱的用using声明了文件流。不过虽然没有直接解决，但却提供了几种出现此问题的猜想。
- 文件读写流未关闭----已排除；
- 在文件写的时候可能没有完全覆盖原有的内容，举个例子一个文件原来有40个字符，但你在重写的时候只写了32个字符，操作系统（不靠谱的windows）可能没有完全按照你想的写完，导致前32个字符是你重写的，后面8个字符是上次的情况（此情景是我猜想，不保证真实发生）；
对应上述两个可能的问题给出如下解决方案：
- 关闭读写流---IT码农还是不要犯这个错了。。
- 问题二有两个解决方案：
- 在保存文件之前，将之前的文件删掉----不过要注意文件在delete的时候即便删除成功也可能会抛出异常，你还没保存就退出了。。。不靠谱的操作系统啊！！！这样导致的问题就是你的数据丢失了，之前的也没了，之后更新的也没了，祈祷数据不值钱吧。。。
- 保存的时候用文件流的方式，声明文件流的filemode属性为truncate（截取模式，即文件流在写时先截断到0字节），保证filestream在写入之前为空的，这样在保存的时候就可以保证不会出现其它的内容。---在声明filestream的时候可能会报异常，但此时原文件不会被更改，只是丢失了新更新的内容。
如上所述，方案二的第二个方法，也是存在丢数之类的问题，但数据库也会存在这种问题（正在进行大数据量的写操作时，突然断电---很极端的一个例子），只是数据库的数据单元很小，完成更改时的单元小，损失就小罢了。当然数据库在大多数情况下要比我们自己写的文件存储靠谱多了，但没办法客户希望部署方便，xml的优势数据库无法比啊。。。
不知道有没有人遇到同样的问题，欢迎讨论。