[281] in The Cryptographic File System users list
CFS and files with holes
daemon@ATHENA.MIT.EDU (maf@tkrat.org)
Tue Jan 7 02:21:54 2003
From owner-cfs-users@crypto.com Tue Jan 07 07:21:54 2003
Return-Path: <owner-cfs-users@crypto.com>
Delivered-To: cfs-mtg@CHARON.mit.edu
Received: (qmail 26155 invoked from network); 7 Jan 2003 07:21:53 -0000
Received: from softdnserror (HELO mx.crypto.com) (207.140.168.138)
by charon.mit.edu with SMTP; 7 Jan 2003 07:21:53 -0000
Received: (from majordomo@localhost)
by MultiHostMXServer (8.9.3/8.9.x4) id BAA32386
for cfs-users-list; Tue, 7 Jan 2003 01:54:20 -0500 (EST)
Received: from dockmaster.research.att.com (H-135-207-24-155.research.att.com [135.207.24.155])
by MultiHostMXServer (8.9.3/8.9.x4) with ESMTP id BAA25939
for <cfs-users@crypto.com>; Tue, 7 Jan 2003 01:54:19 -0500 (EST)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
by dockmaster.research.att.com (8.12.1/8.12.1) with ESMTP id h075twxi014669
for <cfs-users@nsa.research.att.com>; Tue, 7 Jan 2003 00:55:58 -0500 (EST)
Received: by mail-blue.research.att.com (Postfix)
id 4E8C94CFD0; Tue, 7 Jan 2003 01:53:49 -0500 (EST)
Delivered-To: cfs-users@research.att.com
Received: from janus (fpfw.research.att.com [135.207.1.2])
by mail-blue.research.att.com (Postfix) with SMTP id F30584CE83
for <cfs-users@research.att.com>; Tue, 7 Jan 2003 01:53:48 -0500 (EST)
Received: from mail-pink.research.att.com ([192.20.225.111]) by janus; Tue, 07 Jan 2003 01:53:48 -0500 (EST)
Received: (from postfixfilter@localhost)
by mail-pink.research.att.com (8.11.6/8.11.6) id h076fmD28003
for cfs-users@research.att.com; Tue, 7 Jan 2003 01:41:48 -0500
X-Authentication-Warning: mail-pink.research.att.com: postfixfilter set sender to maf@tkrat.org using -f
Received: from tkrat.org (tkrat.math.chalmers.se [129.16.168.189])
by mail-pink.research.att.com (Postfix) with ESMTP id DF96858226
for <cfs-users@research.att.com>; Tue, 7 Jan 2003 01:41:47 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
by tkrat.org (Postfix) with ESMTP id BCB282FCC
for <cfs-users@research.att.com>; Tue, 7 Jan 2003 07:47:44 +0100 (MET)
Date: Tue, 7 Jan 2003 07:52:57 +0100 (CET)
From: maf@tkrat.org
Reply-To: maf@tkrat.org
Subject: CFS and files with holes
To: cfs-users@research.att.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-Disposition: INLINE
Message-Id: <20030107064744.BCB282FCC@tkrat.org>
X-Spam-Status: No, hits=2.1 required=5.0
tests=NO_REAL_NAME,SPAM_PHRASE_00_01
version=2.43-cvs
X-Spam-Level: **
Sender: owner-cfs-users@crypto.com
Precedence: bulk
I recently found out that cfs has some limitations in the support for
files with holes in them. They do work but a read() from a hole returns
random data (close enough at least:-) instead of zeros which one would
expect. I found the following comment in the code (in readblock()):
/* note that we are violating standard unix semantics here - we have
no way to distinguish between zeros in the encrypted file and
holes in the file, which should be returned to the user as
zeros. This could be fixed by detecting that we're creating
holes at write time and filling w/ encrypted zeros, but that
violates other semantics. */
My question now is which other semantics does the comment refer to? And
are really breaking them worse than not returning zeros in the holes?
/MaF
