Lines Matching refs:rename

25 4) rename() that is _not_ cross-directory.  Locking rules: caller locks
45 6) cross-directory rename.  The trickiest in the whole bunch.  Locking
77 (1) if object removal or non-cross-directory rename holds lock on A and
79     acquire the lock on B.  (Proof: only cross-directory rename can change
82 (2) if cross-directory rename holds the lock on filesystem, order will not
83     change until rename acquires all locks.  (Proof: other cross-directory
107 Any contended object is either held by cross-directory rename or
109 operation other than cross-directory rename.  Then the lock this operation
112 It means that one of the operations is cross-directory rename.
115 own descendent.  Moreover, there is exactly one cross-directory rename
118 Consider the object blocking the cross-directory rename.  One
119 of its descendents is locked by cross-directory rename (otherwise we
121 means that cross-directory rename is taking locks out of order.  Due
123 But locking rules for cross-directory rename guarantee that we do not
129 the only operation that could introduce loops is cross-directory rename.
130 Since the only new (parent, child) pair added by rename() is (new parent,
132 would have to exist before rename().  I.e. at the moment of loop creation
133 rename() responsible for that would be holding filesystem lock and new parent
136 we had acquired filesystem lock and rename() would fail with -ELOOP in that
142 also preserved by all operations (cross-directory rename on a tree that would