From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 18:30:12 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 754CB16A4EB for ; Wed, 9 Jun 2004 18:30:12 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-172-121.dclient.hispeed.ch [80.219.172.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9682043D1F for ; Wed, 9 Jun 2004 18:30:10 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:ac79:0:250:daff:fe5a:2107]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i59IU4650287 verified NO) for ; Wed, 9 Jun 2004 20:30:08 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i59IU3W50283; Wed, 9 Jun 2004 20:30:03 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Wed, 9 Jun 2004 20:30:03 +0200 (CEST) Message-Id: <200406091830.i59IU3W50283@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL To: freebsd-stable@freebsd.org From: Barry Bouwsma References: <200406080903.i5893AO01551@Mail.NOSPAM.DynDNS.dK> <40C70CF0.5080304@geminix.org> Subject: Re: patch for unionfs mounts X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 18:30:12 -0000 Uwe Doering wrote: > > +++ union_vnops.c Tue May 11 14:49:02 2004 > > + ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; > I'm afraid there is a problem with this approach. 'va_fsid' and > 'va_fileid' end up as 'st_dev' and 'st_ino' on the application level > ("struct stat"). The combination of these two variables is supposed to > be unique, at least by convention. Software relies on the assumption > that if 'st_dev' and 'st_ino' are identical for two files it is actually > the same file. > Now, by forcing 'va_fsid', and therefore 'st_dev', to the same value > (the unionfs mount's file system id) regardless of which device (file > system) the file is actually located on this patch introduces ambiguity. > There can be two different files with the same 'va_fileid' value (the > inode number, for instance), living on two different file systems, that > now appear to be the same file due to the "fake" value in 'va_fsid'. Hmmm, thanks for the explanation. Too good to be true... It sounds as if I've been lucky since the directories I've unionfs-mounted have been contained within one filesystem (/usr/local/source-hacks atop /usr/src; /usr being common). > This is going to break existing software. So I recommend against > committing this patch to the FreeBSD CVS repository. I have no idea how > else to fix your initial problem, but this patch is not the way to do > it, IMHO. So I'm fixing one problem (for myself), but potentially causing others -- for example, if I had /var/source-hacks mounted atop /usr/src then I'd definitely be seeing problems. Is this correct? By the way, I finally grepped my archives in case I had overlooked discussion about this patch when originally propsed, and found the original message from 25.Feb 2002, and one followup. archive/2002/freebsd-hackers/20020303.freebsd-hackers.gz Message-Id: <200202251435.XAA91094@shidahara1.planet.sci.kobe-u.ac.jp> (followup in the following week's archive as Message-Id: <200203060047.g260l4K29454@green.bikeshed.org> ) (sorry this isn't an online-friendly clickable link) Anyway, until a real fix can be applied, I'll keep this hack locally (and use it carefully). As far as alternatives, I'm not sure if it's worth hacking csh and so on to act as bash, or if I should look at the kernel getcwd() call, and anyway, I'm no hacker, and lazy, and any hacks would probably also be local-only... Many thanks for your feedback! barry bouwsma