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

[David Holland <dholland-bugs%netbsd.org@localhost>]

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

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: Robert Elz <kre%munnari.OZ.AU@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: kern/41678: unionfs doesn't copy a file from the lower layer
        to the upper layer on rename(), it just fails
Date: Sun, 16 Aug 2009 05:45:22 +0000

 On Wed, Aug 12, 2009 at 10:45:02AM +0000, Robert Elz wrote:
  >    | 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.
 
 I dunno, unionfs inherently breaks that assumption (that the inode
 number of a given file doesn't change) in lots of other places.
 
 The alternatives look markedly worse, anyway. :-|
 
 I think what's fundamentally needed for unionfs is for someone to sit
 down and work out (formally, if necessary) exactly what the semantics
 are supposed to be.
 
 My guess is that any such attempt will fail. I think the reason it has
 so many problems is that all the things it's trying to do at once are
 mutually inconsistent.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost