Re: kern/41678: unionfs doesn't copy a file from the lower layer to the upper layer on rename(), it just fails

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/41678; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/41678: unionfs doesn't copy a file from the lower layer to 
the upper layer on rename(), it just fails 
Date: Wed, 12 Aug 2009 17:41:44 +0700

     Date:        Tue,  7 Jul 2009 10:50:01 +0000 (UTC)
     From:        msporleder%gmail.com@localhost
     Message-ID:  <20090707105001.9478E63B976%www.NetBSD.org@localhost>
 
   | I guess when a rename is passed to the lower layer it should be turned
   | into a copy at the upper layer and then a rename.
 
 It can't really, that would have he effect of changing the inum
 (and more) which a successful rename(2) isn't supposed to do.
 
 Just leaving it returning EXDEV seems to be vaguely reasonable to
 me - normally a rename that affects only the final component of a
 pathname wouldn't ever hit that, but in general applications doing
 rename() need to be aware of the possibility and do their own copy
 and unlink if that's suitable for their purposes.
 
 Otherwise, a fix is going to need the combination of a whiteout to
 hide the lower (old) name (easy enough) and probably a new magic kind
 of symlink type object, invisible even to lstat(), with the semantics that
 it's target name is searched in the lower directory (only).  What
 that object would mean when seen in the upper filesys when it isn't
 union mounted I have no idea at all.
 
 I guess a third possibility would be to simply let the rename operate
 wholly on the lower layer (actually changing the lower filesys), but
 I think that breaks the purpose of unionfs, and is not without problems
 of its own.
 
 kre