From owner-freebsd-questions@FreeBSD.ORG Wed Jan 21 05:39:25 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BDAD16A4CE for ; Wed, 21 Jan 2004 05:39:25 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3273B43D2D for ; Wed, 21 Jan 2004 05:39:20 -0800 (PST) (envelope-from freebsd-security-local@be-well.ilk.org) Received: from be-well.no-ip.com ([66.30.196.44]) by comcast.net (sccrmhc13) with ESMTP id <2004012113391901600j4lh5e>; Wed, 21 Jan 2004 13:39:19 +0000 Received: by be-well.no-ip.com (Postfix, from userid 1147) id 59A10F; Wed, 21 Jan 2004 08:39:19 -0500 (EST) Sender: lowell@be-well.ilk.org To: Tillman Hodgson References: <20040114134215.GA21307@sheol.localdomain> <20040114180931.GA17074@miracle.mongers.org> <20040114182154.GA22444@sheol.localdomain> <20040114182755.GX50342@horsey.gshapiro.net> <44oet5mivk.fsf@be-well.ilk.org> <20040120231918.GS24105@seekingfire.com> <447jzmcewz.fsf@be-well.ilk.org> <20040121004728.GV24105@seekingfire.com> <44ptdeazqf.fsf@be-well.ilk.org> <20040121012048.GW24105@seekingfire.com> From: Lowell Gilbert Date: 21 Jan 2004 08:39:19 -0500 In-Reply-To: <20040121012048.GW24105@seekingfire.com> Message-ID: <44vfn54e0o.fsf@be-well.ilk.org> Lines: 66 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-questions@freebsd.org Subject: Re: mtree vs tripwire X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2004 13:39:25 -0000 Tillman Hodgson writes: > On Tue, Jan 20, 2004 at 07:53:44PM -0500, Lowell Gilbert wrote: > > Tillman Hodgson writes: > > > On Tue, Jan 20, 2004 at 07:40:28PM -0500, Lowell Gilbert wrote: > > > > Hmm. I've never had this problem, and when I try to trigger it > > > > deliberately, I find that my mtree specification has the spaces in the > > > > filenames escaped. > > > > > > > > e.g., > > > > foo\040bar\040baz \ > > > > > > Interesting. I'm using -STABLE as of Jan 7/04 on this box ... is your > > > mtree by any chance from -CURRENT? > > > > No, it's -STABLE within the last few days. > > > > Any chance you could generate a test case that demonstrates the > > problem on your system? > > I tried `touch`ing files to create them with spaces, and they ended up > encoded as follows: > > # ./test > /set type=file uid=0 gid=0 mode=0644 nlink=1 flags=none > test type=dir mode=0755 nlink=2 size=512 time=1074647709.0 > this\040is\040a\040file\040with\040spaces.txt \ > size=0 time=1074647708.0 \ > sha1digest=da39a3ee5e6b4b0d3255bfef95601890afd80709 > # ./test > > But when I try to mtree a directory that includes Loki SimCity 3000 > saved games I get files with spaces unencoded: > > # mtree -K sha1digest -c -X mtree.exclude -p /exports/tillman/.loki/sc3u/ > mtree.out > > # ./buildings > /set type=file uid=500 gid=500 mode=0777 nlink=1 flags=none > buildings type=dir mode=0755 nlink=2 size=1024 time=1017616936.0 > Den\040Burg\040Bruges.bld \ > type=link size=39 time=1017616936.0 \ > link=/opt/SC3U/buildings/Den Burg Bruges.bld > Dupont\040House.bld \ > type=link size=36 time=1017616936.0 \ > link=/opt/SC3U/buildings/Dupont House.bld > Garvey\040Plaza.bld \ > type=link size=36 time=1017616936.0 \ > link=/opt/SC3U/buildings/Garvey Plaza.bld > GuestHouse\040Building.bld \ > type=link size=43 time=1017616936.0 \ > link=/opt/SC3U/buildings/GuestHouse Building.bld > etc. > > The filesystem is still UFS2. I'm just NFS exporting my home > directories to several machines, including the RedHat 7.3 box that > originally generated the sc3u save files. > > I'm not /that/ worried about it: I should exclude home directories from > mtree for this "tripwire replacement" purpose anyway. But it's worrisome > that it /could/ fail in this way. Unless we can establish what "this way" is, there isn't much we can do about it. It sounds like you've tried to create your test on the same filesystem as the files that were showing the problems, so I'm not sure what else to check. Maybe you can see some differences in the directory listings themselves?