bug1 rename 特殊情况

1、从编辑器打开文件的过程是先打开临时文件写入。然后将临时文件更名为当前文件名。
2、这样造成，如果打开临时文件，文件会依然可以找到。错误。
3、如果打开改名后的文件，会建立新的文件。

4、如果文件在release 的过程中打开了。n_links==0 才会释放。如果是读取了。

5、正在被使用的文件。需要一个地方存放起来。然后我们需要根据文件的使用状况，判断一些操作是否可以进行。

6、一个对象的生命周期。许多操作都需要使用这个对象。我们要全部考虑他们的情况。"不喜欢等待",这个喜好并不好。有的是事情必须一个个来。

7、不适用dir中的file对象。我们需要定期的清除dir。我们不确定它删除的时机。使用起来有了交集。file对象本身是否可以唯一存在。

8：file 对象的生命周期。正在被操作的文件对象
   开始：open一个文件。
   结束：正常release 一个文件。其他：unlink
   生命活动：write、read、runcate
   rename：从正在活动的map 中清理出来，需要添加另外一个。最好保证filemapusing的修改是锁住的。锁的第一个想到的对抗者就是效率。但是这里需要理性的分析。在整个的大环境下，考虑效率才能真正有帮助。需要考虑我们时间的单位，需要知道我们整个活动的时间。我们锁住部分的时间。这样会很清楚我们这样做到底有多大的影响。这是需要思考的。
   它对现在活动文件列表有影响。名字改掉了。如果其他对象要使用，那么就要另外一个名字。这里注意
更名应该在文件修改完毕后。这样，如果一个文件正在处于写后的release 中，那么他应该等待这个完毕。
我们可以让大家快点。但是如果出现了后面让程序会错误的情况。那么之前该等待的就放在这里了。这种策略应该是较为常用的。对效能的改变也很可观。

   严格约束条件：保证一个文件使用的过程中，无其他线程使用。大家必须有先后，
   在read 处本身是有锁存在的。如果是读取的正在修改的。
  
   失控：文件会一直被打开修改。没有release情况。文件一直是在使用状态。不会根据服务器做改动。
   事务中间存在的几个线条。运行期间有多个线程。有的线程是交互的，有的线程是没有关系的。这样形成了一组组的线程关系。这种关系让大家的关系变得宽松。处理的事务明确下来，事务边界是确定的。
   在实际使用的环境中，可能有一部分理想的东西是没有办法完全保证的。我们可能不愿去触碰这些。我们不得不允许它们存在。但是我们需要明确它们的范围。不能让本应该清楚的部分被分配成为这样。另外，我们需要在它们真的发生后，看能提供什么样的后续处理。保证情况还是正常的。

9、它好像是随意的，无序的。好像任何情况都有可能发生。实际上他是一个序列的组合。组合是有限的。但是它不是一两种，我们思考或者分析的方式局限在一两种的范围。所以无法分析它的全部。所以造成了我们总是只见到一部分。这种情况下，就有了开始的感觉。解决的方法很简单。把所有的情况都列出来，一一分析。分成两个步骤。1、根据收集的信息，把操作单元集合分析出来。根据集合的排序来任意组合。把组合中可能发生的情况标明。在这些情况中可能发生的问题。
   通用过程是这样。具体的情况下，有些问题的细节需要考虑。

10、我们设计的部分。和其他的模块有着关联。可能我们的一部分情况由于其他模块的影响不可能出现了。
这个时候我们有两种选择：分析其他的模块，明确哪些情况是不会发生的。我们根据这种情况做处理。另外我们不假设，按照通用的方式来处理。如，系统发送过来的请求可能进行了顺序的处理。我们可能不需要保证这样一部分。但如果我们自己处理的方式中又打乱了这种顺序，那么就需要同时保证顺序。另外，就算是会这样，我们依然提供同步保证。这样会让程序本身更独立。设计不会过分依赖与其他的模块。

11、编程不是什么都不做就可以搞定的。思维分析是必须的工具。