Subject: union whiteouts persistence intentional?
To: None <tech-kern@NetBSD.org>
From: theo borm <theo4490@borm.org>
List: tech-kern
Date: 06/07/2006 01:40:12
Dear list members,

While experimenting with unions I came across something that strikes
me as odd, and which I've not found documented in the man page.
Whiteouts seem to be persistent entries in the overlaying directory,
surviving the union being unmounted again, and I'm not quite sure
if this really is the intended behaviour.

An example to explain:

Take three directories with identical content:

# ls -R
one  over two
./one:
test
./over:
test
./two:
test

mount_union "over" on top of "one" and delete "one/test" -> creates a
whiteout for "one/test":

# mount_union over one; rm one/test; ls -R
one  over two
./one:
./over:
./two:
test

So two dirs "empty" as expected. Now unmount and check directories:
# umount one; ls -R
one  over two
./one:
test
./over:
./two:
test

So far everything as expected; "over" is empty, and "one" has its
underlying test file again, and "over" is still empty.

But now the fun starts:

# mount_union over one; ls -R
one  over two
./one:
./over:
./two:
test

apparently the whiteout still exists, and re-whites-out the test file in 
"one"!

# umount one; mount_union over two; ls -R
one  over two
./one:
test
./over:
./two:

Now the whiteout in directory "over" whites-out a completely unrelated
(though of the same name) file in directory "two". Apparently the whiteout
is persistent, resides in the directory "over", and will whiteout any 
file of
the same name until the whiteout itself is deleted. Unfortunately these
persistent whiteouts are not something that can be manipulated:

# umount two; rm over/test
rm: over/test: No such file or directory

all I can do is:
# touch over/test; rm over/test
(this will delete the whiteout)

Was this behaviour intended, or is this a bug?

with kind regards,

Theo.


(the intended use was mount a rw directory on top of a ro source tree,
then compile, clean up /some/ objs, then mount the same dir on top
of a modified source tree with some objs in place (that were deleted
from the overlay), and then link stuff together. Unfortunately this
scheme failed miserably because the whiteouts were unexpectedly
(at least by me) also active in the modified source tree.)