Lines Matching refs:rename

18 4) rename() that is _not_ cross-directory.  Locking rules: caller locks
29 6) cross-directory rename.  The trickiest in the whole bunch.  Locking
56 (1) if object removal or non-cross-directory rename holds lock on A and
58     acquire the lock on B.  (Proof: only cross-directory rename can change
61 (2) if cross-directory rename holds the lock on filesystem, order will not
62     change until rename acquires all locks.  (Proof: other cross-directory
86 	Any contended object is either held by cross-directory rename or
88 operation other than cross-directory rename.  Then the lock this operation
91 	It means that one of the operations is cross-directory rename.
94 own descendent.  Moreover, there is exactly one cross-directory rename
97 	Consider the object blocking the cross-directory rename.  One
98 of its descendents is locked by cross-directory rename (otherwise we
100 means that cross-directory rename is taking locks out of order.  Due
102 But locking rules for cross-directory rename guarantee that we do not
108 the only operation that could introduce loops is cross-directory rename.
109 Since the only new (parent, child) pair added by rename() is (new parent,
111 would have to exist before rename().  I.e. at the moment of loop creation
112 rename() responsible for that would be holding filesystem lock and new parent
115 we had acquired filesystem lock and rename() would fail with -ELOOP in that
121 also preserved by all operations (cross-directory rename on a tree that would