[214] in The Cryptographic File System users list

home help back first fref pref prev next nref lref last post

Re: Moving CFS directory en banc from SPARC to Intel architecture?

daemon@ATHENA.MIT.EDU (Paul Pomes)
Mon Oct 30 00:26:25 2000

From owner-cfs-users@crypto.com Mon Oct 30 05:26:24 2000
Return-Path: <owner-cfs-users@crypto.com>
Delivered-To: cfs-mtg@CHARON.MIT.EDU
Received: (qmail 1930 invoked from network); 30 Oct 2000 05:26:22 -0000
Received: from mx.crypto.com (207.140.168.138)
  by charon.mit.edu with SMTP; 30 Oct 2000 05:26:22 -0000
Received: (from majordomo@localhost)
	by MultiHostMXServer (8.9.3/8.9.x4) id AAA25837
	for cfs-users-list; Mon, 30 Oct 2000 00:13:35 -0500 (EST)
X-Authentication-Warning: mx.crypto.com: majordomo set sender to owner-cfs-users@crypto.com using -f
Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50])
	by MultiHostMXServer (8.9.3/8.9.x4) with ESMTP id AAA28437
	for <cfs-users@crypto.com>; Mon, 30 Oct 2000 00:13:33 -0500 (EST)
Received: from computer (dialup-209.245.36.87.SanDiego1.Level3.net [209.245.36.87])
	by avocet.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id VAA26364;
	Sun, 29 Oct 2000 21:13:16 -0800 (PST)
Message-Id: <200010300513.VAA26364@avocet.prod.itd.earthlink.net>
Date: Sun, 29 Oct 2000 21:13:08 -0700
To: Matt Blaze <mab@research.att.com>
From: Paul Pomes <ppomes@ieee.org>
Subject: Re: Moving CFS directory en banc from SPARC to Intel  architecture?
Cc: cfs-users@crypto.com
Mime-Version: 1.0
Content-Type: text/plain;
     charset = "us-ascii" 
Sender: owner-cfs-users@crypto.com
Precedence: bulk



At 05:11 AM 10/17/00 -0400, Matt Blaze <mab@research.att.com> wrote:

>I've done exactly that operation on exactly those platforms (OK, PIII not PII),
>and everything has worked fine.  Are you *sure* your tar archive actually
>got all the . files in the root of the encrypted directory and restored
>them with correct permissions on your new filesystem (most likely
>problem)?  Are you sure the versions of tar you were using properly handle
>byte order (less likely problem)?

I'm still characterizing the problem but the files and permissions look OK.
A new directory created with cmkdir can be cattach'ed and the file sizes and
permissions of {..c, ..k, ..m} match those of the problem directories.  There
are no byte-order problems with the plaintext files in the tarball.

One significant difference is that the Solaris installation was compiled using
the v5 Sparcworks compiler with -xO5 optimization while the FreeBSD installation
used gcc v2.95 with -O2 (however -O and -g have been tried).

Pending a revelation I'll be asking around UCSD for some time on a sparc
workstation to recreate my old CFS environment.

/pbp


home help back first fref pref prev next nref lref last post