Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
Why is it that the first example here is a problem but the other 2 arent't?
mv a/dir1 a/dir2/newdir mv b/dir2 b/dir1/newdir
mv a/dir1 a/dir2/newdir mv a/dir2 a/dir1/newdir
cd a cd b
mv dir1 dir2/newdir mv dir2 dir1/newdir
Posted Sep 2, 2004 16:27 UTC (Thu) by RobSeace (subscriber, #4435)
Posted Sep 2, 2004 17:23 UTC (Thu) by larryr (guest, #4030)
I think maybe the problem is that unix style filesystem semantics
assume a tree structure, meaning one parent edge/entry for
each vertex/node, but having a hard link to a directory
violates that assumption. I think if it was considered typical for
a directory to have multiple parent pointers, and there were
for performing atomic locking on all the parents of a directory
at once, there might be no problem. But if "the parent"
of a node is assumed by the implementation to be "the node corresponding to the path component to the left of
the path component referencing this node", locking "the parent" of "/x/a/dir1" could be different from locking "the parent" of "/x/b/dir1".
Posted Sep 3, 2004 1:57 UTC (Fri) by vonbrand (subscriber, #4458)
Posted Sep 3, 2004 15:36 UTC (Fri) by larryr (guest, #4030)
No, the problem is precisely that if a diretory has several parents[... ]you'd have to be able to find all parents and lock them before doing anything... and that will have a heavy cost if done naïvely.
was considered typical for a directory to have multiple
parent pointers, and there were consistent conventions for
performing atomic locking on all the parents of a directory
at once, there might be no problem.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds