Lines Matching refs:rename

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