From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net Date: Tue, 18 Sep 2012 23:31:27 -0700 From: Bakul Shah Message-Id: <20120919063127.4FD08B827@mail.bitblocks.com> Subject: [9fans] union directories exploration Topicbox-Message-UUID: ba274b16-ead7-11e9-9d60-3106f5b1d025 I think I understand plan9 union directories but find them limiting for some uses. Consider term% mkdir -p a1/b/c a1/b/d a2/b/c a2/b/e term% touch a1/b1 a2/b2 a1/b/c1 a2/b/c2 term% du -a a1 0 a1/b1 0 a1/b/c 0 a1/b/d 0 a1/b/c1 0 a1/b 0 a1 term% du -a a2 0 a2/b/e 0 a2/b/c2 0 a2/b/c 0 a2/b 0 a2/b2 0 a2 term% bind -a a1 a2 term% du -a a2 0 a2/b/e 0 a2/b/c2 0 a2/b/c 0 a2/b2 0 a2/b1 0 a2/b 0 a2 [Note: redundant entries are deleted] Notice that after the binding, b/d and b/c1 don't show up in a2. This happens because b exists in both directories and once a2/b is traversed, further search is limited to the original a2/ tree. Even if you ls a2/b/c1, it will fail. The behavior I want (making all the file in a1 and a2 visible after binding, with preference to the "before" directory) can be achieved by binding *every* in a1 directories that has a correponding dir in a2, starting with the leaf directories and moving up. term% unmount a2 term% bind -a a1/b/c a2/b/c term% bind -a a1/b a2/b term% bind -a a1 a2 term% du -a a2 0 a2/b/e 0 a2/b/c 0 a2/b/d 0 a2/b2 0 a2/b1 0 a2/b/c2 0 a2/b/c1 0 a2/b 0 a2 [Note: redundant entries are deleted] What I want to do idea is to overlay one tree on another. This idea can be used to overlay a r/w tree on a readonly source tree and do a build. Or even do a concurrent build for different architectures. But there are hundreds of directories in /sys so this can get quite unwieldy and a walk(9) can become more of a shuffle or search. May be this should be called a "labor" union! Has anyone tried this and has a script for this? Is there a better way to handle this (overlay one partial tree on another to provie a different 'view')? Then there are issues with what happens when directories are added or deleted. One almost wants a `Watch' command that watches such changes and does the right thing. Since binds are only allowed on directories, deleting a file foo in the "before" directory can make any file foo in the "after" directory. I guess this is why *BSD unionfs has a `whiteout' file type [this is analogous to a `blackhole' route in a network forwarding table or a `blacklisted' email address in a spam filter. How funny] [Thinking about this makes me appreciate the complexity of *BSD unionfs and why it has never been fully shaken out. May be worth prototyping on plan9]